All of these are unused since af9fbd176b "Introduce a new compositor
architecture". Since no one complained yet, I guess that means that we don't
need these any more. :-)
This was noticed while looking into the build log provided by
http://lists.cairographics.org/archives/cairo/2012-April/022993.html
Signed-off-by: Uli Schlachter <psychon@znc.in>
In order to handle the snapshot copy-on-write losing a race with another
thread using the snapshot as a source, we may find the target acquires a
fresh reference as we attempt to finalize it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the source wins the race to acquire the original surface as it is
being destroyed, it triggers an assertion.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Due to race with cow and accessing target from multiple threads, we need
to be careful that we always acquire a reference for our access to
the snapshot target.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The danger of the incomplete test masking the failure to correctly skip
the degenerate elements in the final dash state.
Fixes the fixed degenerate-solid-dash.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the dash specifies that the pen is always on (i.e. the total of the
off segments is zero), then we can eliminate the dash pattern.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
./cairo.c (634): ERROR: cairo_set_opacity: missing 'Since' field
./cairo.c (3578): ERROR: cairo_get_opacity: missing 'Since' field
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to prevent a race between concurrent destroy and use in another
thread, we need to acquire a reference to the snapshot->target under a
mutex. Whilst we hold that reference, it prevents the internal destroy
mechanism from freeing the memory we are using (if we have a pointer to
the original surface) and the client drops their final reference.
Oh boy, talk about opening a can of worms...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Although 0x0 is not a legimate surface size, we do allow applications
the flexibility to reset the size before drawing. As we previously never
checked the size against minimum legal constraints, applications expect
to be able to create seemingly illegal surfaces, and so we must continue
to provide backwards compatibility.
Many thanks to Pauli Nieminen for trawling through the protocol traces,
diving into the depths of libreoffice and identifying the regression.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=49118 (presentation
mode in loimpress is blank).
Reported-by: Eric Valette <eric.valette@free.fr>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
_cairo_pdf_surface_add_source_surface allocates unique_id with
size unique_id_length but then copies surface_key.unique_id_length into it.
This causes e.g. evince to crash predictably while trying to print with:
*** buffer overflow detected ***: evince terminated
We should be using surface_key.unique_id_length instead.
Reported-by: Dominique Leuenberger <dominique-freedesktop.org@leuenberger.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49089
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Due to rounding errors that may creep in comparing against 0.0 is
dangerous and may result in an infinite loop whilst generating dashes
that consumes all memory.
Reported-and-tested-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
