As for a native window, the surface does not have an image delegate
itself but instead installs a fallback surface during map_to_image. So
during unmap_image, we then need to unmap from the fallback surface
instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The documentation of cairo_surface_create_similar_image() states that the
image's contents are initially all 0. However, the implementation didn't live up
to the documentation.
This was found via the corresponding assert in
cairo_surface_create_similar_image().
There are some cairo-xcb-internal users of this function which cleared the image
right after creating it. Obviously, this isn't needed anymore.
Fixes: Nothing. The existing call in the testsuite to
cairo_surface_create_similar_image() doesn't hit this issue, since it creates a
too small image to hit the SHM-case.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Søren thought it was bit harsh to lay the blame solely on xorg for it
crashing due to an unexpected input value, and that we should mention
libXext was also partly to blame for incorrectly setting the SEND_EVENT
bit in the ShmCompletionEvent.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Søren Sandmann Pedersen pointed out that all versions of Xorg prior to
and including xorg-1.11.0 contained a bug that would cause them to crash
if they ever processed an event sent by XSendEvent. This was fixed in
commit 2d2dce558d24eeea0eb011ec9ebaa6c5c2273c39
Author: Sam Spilsbury <sam.spilsbury@canonical.com>
Date: Wed Sep 14 09:58:34 2011 +0800
Remove the SendEvent bit (0x80) before doing range checks on event type.
so make sure we do not use XSendEvent prior to that commit, which
fortuitously is quite easy as we only do so along the ShmPixmap path.
Reported-by: Søren Sandmann Pedersen <ssp@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to avoid recursing upon our source mutex when doing a snapshot,
we can perform an explicit copy of the command array. This should also
be faster than performing a replay as well.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50443
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we generate an edge (through polygon-intersect) where its end-points
lie outside the line definition then it is possible for that line to be
degenerate under sample grid projection. Apply a fudge factor to prevent
explosions as otherwise we reject an edge whose height is not strictly
0.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54822
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than using the traps reference for all target as this then
generates false negatives with the spans compositor.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So that the composite-rectangles remains consistent with the reduced
clip in case the individual compositors try to optimise their rendering
strategies based on the reduced clip and the overall extents.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we will be reducing the clip intersection to a single clip box check
during construction, it helps if we use the tight clip box.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This problem was introduced in commit "xlib: Implement SHM fallbacks and fast
upload paths". Before, cairo_surface_mark_dirty() directly called
cairo_surface_mark_dirty_rectangle() with special "magical arguments" and thus
didn't need any checks on the surface status.
Fixes: api-special-cases
Signed-off-by: Uli Schlachter <psychon@znc.in>
This code tried to optimize the clip away by intersecting the boxes with the
clip polygon. However, it also did so when the server didn't support traps.
Fixes: clip-stroke-unbounded clip-fill-nz-unbounded clip-fill-eo-unbounded
clip-fill clip-fill-rule a1-clip-fill-rule clip-group-shapes-circles
clip-intersect clip-nesting clip-operator clip-push-group clip-polygons
clip-shape clip-text clip-twice inverted-clip mask random-clip
rotate-clip-image-surface-paint trap-clip unantialiased-shapes
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit adds lots of asserts. These asserts verify for each extension
request that we send that the server really supports this.
Sadly, this causes 28 assertion failures in the test suite with xcb-render-0.0.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit removes the hand-written code in cairo-xcb-surface.c and instead
makes use of cairo_compositor_t. Surprisingly, this doesn't break a single test
case. :-)
Signed-off-by: Uli Schlachter <psychon@znc.in>
cairo-xcb-surface.c: In function '_drawable_changed':
cairo-xcb-surface.c:1434:39: warning: ignoring return value of '_cairo_surface_begin_modification', declared with attribute warn_unused_result [-Wunused-result]
Signed-off-by: Uli Schlachter <psychon@znc.in>
The inline functions in cairo-backend-private.h tried to dereference a cairo_t,
which wasn't defined. Fix this by including cairo-private.h.
In cairo-mempool-private.h, size_t is used but stddef.h is not included.
Fixes:
CHECK cairo-backend-private.h
In file included from headers-standalone-tmp.c:1:0:
./cairo-backend-private.h: In function ‘_cairo_backend_to_user’:
./cairo-backend-private.h:179:7: error: dereferencing pointer to incomplete type
./cairo-backend-private.h: In function ‘_cairo_backend_to_user_distance’:
./cairo-backend-private.h:185:7: error: dereferencing pointer to incomplete type
./cairo-backend-private.h: In function ‘_cairo_user_to_backend’:
./cairo-backend-private.h:191:7: error: dereferencing pointer to incomplete type
./cairo-backend-private.h: In function ‘_cairo_user_to_backend_distance’:
./cairo-backend-private.h:197:7: error: dereferencing pointer to incomplete type
CHECK cairo-mempool-private.h
In file included from headers-standalone-tmp.c:1:0:
./cairo-mempool-private.h:61:5: error: unknown type name ‘size_t’
./cairo-mempool-private.h:62:5: error: unknown type name ‘size_t’
./cairo-mempool-private.h:68:8: error: unknown type name ‘size_t’
./cairo-mempool-private.h:73:44: error: unknown type name ‘size_t’
Signed-off-by: Uli Schlachter <psychon@znc.in>
Whenever we discard the fallback surface, we need to destroy the
associated damage tracking, so move this into the common discard
routine.
This should fix the issue when trying to flush the fallback before
the user modifies any foreign Drawables. The current code issued the
flush and then explicitly discard the fallback, but unless it was idle
at the time of the flush the associated damage would not have also been
destroyed. Asserts followed.
References: https://bugs.freedesktop.org/show_bug.cgi?id=54657
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Use the higher level layer to be sure we detach any snapshots and other
cached data that is invalidated along with the change of Drawable.
Pointed out by the eternally wise Uli Schlachter.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
_cairo_surface_begin_modification() performs an internal flush, for
which the xlib backend skips flushing the fallback surface as it will
continue to use it for the subsequent operation. In the case where we
are flushing prior to updating the Drawable, we need to perform an
external flush which will trigger the posting of the damage from the
fallback surface.
Reported-by: Weng Xuetian <wengxt@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=54657
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the user changes the size of the underlying drawable, we much make
sure that we discard the current ShmPixmap in order to create a new
fallback pixmap of the correct size next time.
Reported-by: Weng Xuetian <wengxt@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In commit 0bfd2acd35
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Aug 13 01:34:12 2012 +0100
xlib: Implement SHM fallbacks and fast upload paths
I made the mistake of inverting the logic for
cairo_xlib_surface_set_drawable() causing it then to never update.
Thanks to Uli Schlachter for spotting my error.
References: https://bugs.freedesktop.org/show_bug.cgi?id=54657
Reported-by: Weng Xuetian <wengxt@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to flush any fallback to a foreign drawable upon finish.
However, we must be careful not to attach the snapshot in that case or
else we end up with an expected reference. This is similar to the
treatment of xlib/shm in commit f864e2d70.
Reported-by: Henry Song <henry.song@samsung.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes regression from commit 83bfd85a13
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Apr 23 19:45:26 2010 +0100
Implement cairo_backend_t
As there exists no public API to perform the operation we needed, and we
failed to create one, the constructed path failed to correctly remove
the device offset.
Fixes copy-path under device translation.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54732
Reported-by: Benjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In this case we want to prevent the short-circuiting of the flush of the
ShmPixmap that is ordinarily performed during finish().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the surface->backend will be NULL in such an error surface, and we
may be legitimately doing boundary checks to reject the error surface.
The alternative would be to set an explicit error surface backend.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54664
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When transforming the incoming paths, the goal is to transform them from
user space onto the target coordinate system. Currently for relative
paths we used user_to_device_distance as we presumed that there was no
backend scale factor. However, Alex Larsson noticed that these then
broke when playing around with such a device transform...
Reported-by: Alexander Larsson <alexl@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Needs a bit of extra work to create the extension event, but this leaves
the application with only a single spurious event to filter.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We frequently compare neighbouring edges for their colinearity (in case
we can skip over them in the active list) so we can record the last
comparison and reuse the result next time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Albeit it too large for gcc to automatically inline, it is only used
from within a single function. Hopefully gcc can optimise better with
the hint.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
