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>
And not the device_transform of the target. This smells fishy, but
appears to make the test suite happy.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In theory, this should be more cache efficient and allow us to trim the
operation to the width of row, shaving a few texel fetches. The cost is
that we cause pixman to evaluate the composite operation per-row. This
should only be a temporary solution until we can do something better
through pixman...
On a i5-2520m, ymmv,
firefox-fishtank 64585.38 -> 56823.41: 1.14x speedup
swfdec-fill-rate 1383.24 -> 1665.88: 1.20x slowdown
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reducing the number of passes has the usual change in the antialiasing
side-effects, as well as the boon of being faster (and theorectically more
accurate through reduced loss of dynamic range.)
On an i5-2520m:
swfdec-giant-steps-full 3240.43 -> 2651.36: 1.22x speedup
grads-heat-map 166.84 -> 136.79: 1.22x speedup
swfdec-giant-steps 940.19 -> 796.24: 1.18x speedup
ocitysmap 953.51 -> 831.96: 1.15x speedup
webkit-canvas-alpha 13924.01 -> 13115.70: 1.06x speedup
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we have a curvy polygon, we can expect to generate lots of short
trapezoids. However, we may be able to reduce the transport size by
converting them into a set of boxes instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This trick only seems effective with mono-rasterisation, with a win of
about 10% for tiger-demo --antialias=none. At other antialias setting,
performance is reduced.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
