During the surface flush, we reduce any pending damage and then blit. If
no damage had been accrued then the damage->region would be NULL leading
to a segfault.
Patch suggested by Szuromi Gábor.
Reported-by: Szuromi Gábor <kukkerman@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47605
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Just emit a marker for when cairo_image_surface_get_data() is called on
a surface so that we have a breadcrumb for when the pixels are first
exported. (Though note that pointer may be kept around and used much
later.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When cairo_surface_create_for_rectangle() is given non-integer parameters,
the subsurface's size may be negative(e.g x = 0.2, width = 0.7, the
final width will be -1). This illegal surface may cause crash somewhere
upon later use, and although the fractional subsurface is ill-defined,
we should never crash!
The extents->clip may be replaced elsewhere and so we cannot assume that
simply because it changed from the stashed value, that it was us that
made that copy. So becareful to only free our copy.
Fixes a double-free of a clip after a complex fallback operation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The earliest use of the clip path's polygon fill rule is now for
intersecting the original polygon with the plurality of clip boxes.
However, the initialisation of the fill rule remained after the
intersection.
==8968== Conditional jump or move depends on uninitialised value(s)
==8968== at 0x4C99449: _cairo_polygon_intersect (cairo-polygon-intersect.c:1382)
==8968== by 0x4C9B788: _cairo_polygon_intersect_with_boxes.part.12 (cairo-polygon-intersect.c:1520)
==8968== by 0x4C6AE6E: _cairo_clip_get_polygon (cairo-clip-polygon.c:104)
==8968== by 0x4CAA667: clip_and_composite_boxes.part.13 (cairo-spans-compositor.c:773)
==8968== by 0x4CAAD1D: clip_and_composite_boxes (cairo-spans-compositor.c:758)
==8968== by 0x4CAB25C: _cairo_spans_compositor_fill (cairo-spans-compositor.c:1023)
==8968== by 0x4C6CB69: _cairo_compositor_fill (cairo-compositor.c:184)
==8968== by 0x4C7CE3E: _cairo_image_surface_fill (cairo-image-surface.c:945)
==8968== by 0x4CAE2B6: _cairo_surface_fill (cairo-surface.c:2047)
==8968== by 0x4C74AB7: _cairo_gstate_fill (cairo-gstate.c:1268)
==8968== by 0x4C6E6D3: _cairo_default_context_fill (cairo-default-context.c:1009)
==8968== by 0x4C67944: cairo_fill (cairo.c:2105)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Empty for the moment as there is no need to cross-reference the files in
git against the list in the Makefile anymore, but the release process
still requires it - and it may prove to be useful again in the future.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The pen is only used for ensuring that we generate consist vertices
around a fan used for end-capping or line-joining when set to ROUND.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The earlier bug found in edge advancement was actually due to the missed
opportunity of not performing the increment when we know the step is
zero.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whilst we wait for IvyBridge with its fast integer divide, in the
meantime avoid the overhead by inspecting a smaller simpler cache before
doing the full hash table lookup.
Shaves around 10% off glyph microbenchmarks for -image.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
cairo_win32_scaled_font_create_for_logfontw() does not exist. Probably
cairo_win32_font_face_create_for_logfontw() was meant instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The names of the function arguments in the function prototype and
in the description comment must match, otherwise gtk-doc is confused.
When the argument names differ between function prototype and
definition, use the names from the prototype.
Also add a missing colon.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Using the programlisting tag is not appropriate everywhere. Use the
screen tag where the formatting shall be preserved and the text is no
code listing.
Also add whitespace to prevent gtk-doc from inserting paragraph breaks.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Despite copying across the font options from the PDF backend, it still
looks like the image surface is override the glyph placement... Odd.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Recently I began using the surface->snapshot_of member of a subsurface
to cache a target representation of the current subsurface. More
recently, I discovered this caused an assertion failure in epiphany, and
probably other GTK3 based programs.
Throwaway the assertion and trust that the programmer doesn't make any
mistakes...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Only texture surfaces need to have a depth-stencil attachment.
The default framebuffer is responsible for managing its own
depth and stencil attachments.
The (dst_x, dst_y) parameters passed to the XRenderCompositeText are
misleading and do not perform any adjustment, so we have to do it
ourselves.
Fixes clip-operator
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Both combine-with-clip functions now take care of any intersection with
clip boxes so the result would be to have overdrawn the unaligned clip
box mask twice.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we have more than a single box, run the boxes intersection as a
post-processing step on the clip polygon, as it should be faster than
doing it inline.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
