Flushing only releases the fallback if we flush twice with no
intervening damage (the theory is to try and reduce readbacks). So it is
possible for a correctly behaving application to call mark-dirty and there
still be a fallback.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The gradient is relatively small and any differences between upload
methods should be hidden by the caching. As it stands, using pbo with
the gradient fails with fglrx. As the workaround to use a simple
TexImage2D is inconsequential (may even be a minute win) and simplifies
the code, just do it.
A couple of mistakes, such as inverting the logic as to when to flush
damage back from the shadow, meant that nothing happened when drawing to
the directfb surface.
Again still only compile tested.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The damage wasn't being created on the right surface, so the damage to
the fallback image surface was not being tracked. Perform a little bit
of juggling so that we track dirty regions on the fallback surface itself.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
