We want to avoid unnecessary readback and so only want to use the
ShmPixmap when uploading the complete surface.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having extracted the code for use by the SHM allocator for xlib, remove
the now redundant copy from xcb.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
46d79228 did indeed silence the compilation warning, but did so by never
creating an ARGB32 format, as PictStandardARGB32 is defined to 0. Fix
this by using PictStandardNUM as our canary value instead.
This fixes GEdit and Chromium for me, both of which were only rendering
backgrounds and text in their GTK+ sections.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
As the easiest approach to making another snapshot that only depends
upon a stable pixman, make the new dependency a compile time option.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to generate the correct left-hand border color, we need to
fudge the offsets of the color stops if multiple stops are defined at 0.
The reason is that pixman will generate our color ramp by using the
right-most color stop for the pixel centre, but in order to provide the
sample colour outside of the gradient we need pixel 0 to be have the
left-most color.
Reported by Henry Song.
If the gradient contains a step function, we need an infinitely sharp
texture to emulate the correct output. Failing that, lets just use as
large a texture as can be reasonably handled by the hardware
cairo-xlib-display.c: In function '_cairo_xlib_display_get_xrender_format':
cairo-xlib-display.c:519:21: warning: 'pict_format' may be used
uninitialized in this function [-Wmaybe-uninitialized]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
cairo-gl-glyphs.c: In function '_cairo_gl_composite_glyphs_with_clip':
cairo-gl-glyphs.c:442:9: warning: unused variable 'i' [-Wunused-variable]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Mesa changed the name of the extension it invented, so check for the
real name and the old name before falling back to pbuffers which are not
supported by most EGL implementations.
References: https://bugs.freedesktop.org/show_bug.cgi?id=53361
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the source and destination are on difference devices (GL contexts) we
can not simply texture from one to the other, and must either import the
source into the destination context (which has not yet been done) or
fallback through an image copy.
This patch is based on the work by Henry Song, but moving the check from
the common compositor layer down into the GL backend. This should have
the same effect...
Fixes gl-surface-source
Suggested-by: Henry Song <henry.song@samsung.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Recording surfaces should be replayed with the transform matrix used
in the pattern, otherwise the image surface will be transformed,
introducing artifacts.
Fixes record{1414x,2x}-paint-alpha-{,solid-clip,clip},
record2x-{self-intersecting,text-transform} and record90-paint-alpha.
_cairo_clip_intersect_clip_path_transformed() completely ignored the
transformation matrix instead of transforming all the clip paths with
it.
This caused bugs when replaying recording surfaces.
Fixes record{2x,1414x,90}-paint-alpha-clip-mask.
The xcb private header uses the ASSERT_NOT_REACHED macro.
This macro is defined in cairoint.h, which needs to be included.
Fixes:
CHECK cairo-xcb-private.h
In file included from headers-standalone-tmp.c:1:
./cairo-xcb-private.h: In function ‘_cairo_xcb_connection_shm_put_image’:
./cairo-xcb-private.h:636: error: ‘ASSERT_NOT_REACHED’ undeclared (first use in this function)
./cairo-xcb-private.h:636: error: (Each undeclared identifier is reported only once
./cairo-xcb-private.h:636: error: for each function it appears in.)
So check for the appropriate surface type at the start and return
UNSUPPORTED if we cannot handle it directly. We will then fallback to
pushing the image instead.
Together with the previous patch, fixes 8 fails in cairo-test-suite.
When the source surface type is gl-window, we should return unsupported
and then create a new texture surface for it. Based on the code of
Henry's tree.
In _cairo_gl_surface_map_to_image(), the image surface data has been
filled by glReadPixels, so is_clear flag should be set to FALSE.
Otherwise mapped image surface does not get drawn as it is presumed
clear and so returns true from nothing_to_do().
We must destroy glyph cache surface in device_finish instead of in
device_destroy because in device_destroy device status is
DEVICE_FINISHED and the operation is invalid.
The size of the target area doesn't really have much to do with the size of the
recording surface that we are painting from. Thus, let's use the recording
surface's size instead.
Since we apply the transformation before replaying the recording surface, we
need to transform the recording surface's size via the inverse of our pattern
matrix to get the size in the target surface. This makes this a little more
complex.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Let's say we are painting recording surface 'source' to xcb surface 'target' by
replaying the source to a temporary surface 'tmp'.
Previously, the xcb backend replayed the recording surface to tmp with just a
translation and then used that as its source surface with the pattern's
transformation. That means 'tmp' used the same coordinate system as 'source'.
This patch changes this so that the transformation is applied during the replay
and painting from 'tmp' to 'target' is just a simple translation, so 'tmp' now
uses the same coordinate system as 'target'.
This should produce way less better results, because transforming a recording
surface should have less artifacts than transforming a raster surface.
Fixes: record1414x-* record2x-* record90-* ps-surface-source
Breaks (or rather, "exposes unrelated bug that I have not yet figured out in"):
record-extend-*-similar
Signed-off-by: Uli Schlachter <psychon@znc.in>
When the desintation surface is not a texture, it is flipped in the Y
axis. So we need to correct the Y coordinates when using glScissor to
the set the clip region.
Fixes 14 cases in cairo-test-suite, for example partial-clip-text-top
If the angle between two segments is small we can simply replace the
round-join with a bevel-join. This is done automatically by the
insertion of the triangle fan as it will not be able to find a point
around the pen between the two vectors. However, we can make that search
cheaper by inspecting whether the bisection angle is small enough that
the bevel-join will be within geometric tolerance of the round-join.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Near an inflection, the angle between two segments of a spline increases
rapidly (as the radius of curvature decreases for the cusp). The angle
may increase so much that a simple line connecting the two outside
points of the spline is not within the user specified geometric
tolerance (with the result that you can generate severe ugliness around
a cusp). Extend the current detection of the exact inflection to cover
the sharp joins near the cusp by inspecting whether the bisection angle
is larger than acceptable.
Fixes bug-spline.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the case we try to use an unbounded operation, passing a NULL clip
causes that operation to clear the rest of the surface. Instead we need
to trim the _cairo_surface_mask() to the operation extents.
Fixes overlapping-glyphs.
Suggested-by: Chuanbo Weng <strgnm@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Jose Dapena Paz reported an assertion following the uninitialised status
value being returned. Also the function failed to free its allocations.
Based on a patch by Jose Dapena Paz <jdapena@igalia.com>.
Reported-by: Jose Dapena Paz <jdapena@igalia.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51104
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
_cairo_surface_subsurface_set_snapshot () sets the subsurface as the
snapshot of its target. This creates a reference cycle (as the target
is already referenced by the surface) and thus a memory leak (assuming
the likely case that user doesn't call finish).
Test case: subsurface-similar-repeat.
So make this call as a no-op for the time being until the bug is fixed.
quartz-image uses _cairo_surface_is_image(), which is now declared in
cairo-image-surface-inline.h.
Fixes:
cairo-quartz-image-surface.c: In function 'cairo_quartz_image_surface_create':
cairo-quartz-image-surface.c:312: error: implicit declaration of function '_cairo_surface_is_image'
cairo-quartz-image-surface.c:312: warning: nested extern declaration of '_cairo_surface_is_image'
This new pixman API allows glyphs to be cached and composited in one
go, which reduces overhead compared to individual calls to
pixman_image_composite_region32().
Notes:
- There is an explicit call to _cairo_image_scaled_glyph_fini(). This
could instead be done with a private, but I chose not to do that
since we don't need to store any actual data; we only need
notification when the glyph dies.
- The slowdown in poppler-reseau is real and stable across runs. I'm
not too concerned about it because this benchmark is only one run
and so it is dominated by glyph cache setup costs and FreeType
rasterizing.
Performance results, image backend:
Speedups
firefox-talos-gfx 5571.55 -> 4265.57: 1.31x speedup
gnome-terminal-vim 1875.82 -> 1715.14: 1.09x speedup
evolution 1128.24 -> 1047.68: 1.08x speedup
xfce4-terminal-a1 1364.38 -> 1277.48: 1.07x speedup
Slowdowns
poppler-reseau 374.42 -> 394.29: 1.05x slowdown
Performance results, image16 backend:
Speedups
firefox-talos-gfx 5387.25 -> 4065.39: 1.33x speedup
gnome-terminal-vim 2116.66 -> 1962.79: 1.08x speedup
evolution 987.50 -> 924.27: 1.07x speedup
xfce4-terminal-a1 1856.85 -> 1748.25: 1.06x speedup
gvim 1484.07 -> 1398.75: 1.06x speedup
Slowdowns
poppler-reseau 371.37 -> 393.99: 1.06x slowdown
Also bump pixman requirement to 0.27.1.
This is hopefully a lesser used path and the attempted optimisation to
continue a stopped edge with a colinear stopped edge highly unlikely and
lost in the noise of the general inefficiency of the routine. As it was
broken, rather than attempt to rectify the "optimisation" remove it.
Reported-by: Evangelos Foutras <evangelos@foutrelis.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50852
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As it turns out due to the rules of polygon intersection, there is never
any overlapping spans so the choice is arbitrary. However, lets be
consistent with the rest of the code.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
