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>
Currently we construct a mask for the entire line and try to process it
in one call to pixman (two without the LERP operator). An alternative
approach is split the row into separate composite operations for the
clear (which we can skip), fully opaque and partial spans.
As the source operator is typically mostly opaque or clear, this is a
good win as we are able to utilise more fast paths. In the worst case,
it degrades to the old method of constructing a whole mask for a row.
It may reduce performance for having to process lots of spans though
(this is where the pixman spans interface should help). However, such
geometry is rare and typically handled elsewhere.
And the existing code has a bug where it was clearing the destination
for clear regions of the mask outside of the spans.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The Title: field is used to determine the file name of the generated
html. Due to the slash a subdirectory is created and all relative links
in the generated file are broken.
Use a hyphen instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
