Test case for bug 89232 - painting a recording surface to a
pdf/ps surface omits objects on the recording surface with negative
coordinates even though the pattern matrix has transformed the objects
to within the page extents.
The image surface also fails when the recording surface is bounded.
The surface_transform was already used surface_replay_with_clip, as the
matrix is obviously needed for the clip. But now, because of the
optimization done in commit 09b42c7, it's also needed by
replay_and_create_regions: get_target_extents clips the target surface
for performance issues, and therefore needs the surface_transform matrix
to get the right clipping surface.
Signed-off-by: Guillaume Ayoub <guillaume.ayoub@kozea.fr>
This adds _cairo_atomic_int_get_relaxed and _cairo_atomic_int_set_relaxed which
are meant to have a behaviour of relaxed read/writes in C11's memory model. This
patch also uses these new function to fix a data race with freed_pool_t's |top|
data member.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=90318
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
We need to link against libdrm to use its functions.
Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weigelt@gr13.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
These functions have been accidentially removed by commit:
494cfd7eb9.
They're still needed by the DRM backend.
(will be used by subsequent patches)
Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weigelt@gr13.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Cc: Uli Schlachter <psychon@znc.in>
Looking back at past release announcements, it's been a long time since
we included the About Cairo bits. This info is easily located on the
website and elsewhere, no need for the redundant data in the
announcement too.
The document uses X.Y.Z to sometimes mean the previous release version,
and in other places to mean the upcoming next release version. Identify
these more explicitly.
NextRequest is a macro that doesn't mix well with xcb, since
dpy->request is not updated. Instead use XNextRequest() that was fixed
to do the right thing with xcb in libX11 commit:
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=7f8f9a36ef901f31279c385caf960a22daeb33fe
This may solve application X errors when a shmdt() is called by cairo
before the Attach request is processed.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is broken since:
commit b1192beac7
Author: Adrian Johnson <ajohnson@redneon.com>
Date: Mon Sep 21 21:35:05 2015 +0930
Don't cull very thin lines on vector surfaces
On vector surfaces, use a minimum line width when calculating extents.
Bug 77298
Signed-off-by: Uli Schlachter <psychon@znc.in>
As the page size can be changed between pages, set the extents in
_start_page. The extents are invalidated in _show_page since the
page size on the DC may be changed after this call. The only thing that
uses the extents between _show_page and _start_page (and before the first
_start_page) is the creation of the recording surface in the paginated
surface. In this case, when the paginated surface can't get the extents,
it will create an unbounded recording surface.
The extents x,y is always set to 0 to prevent the replay from translating
the page.
ARM has much weaker memory ordering guarantees than x86 by default, and
needs the memory barriers. A similar fix exists in the Skia codebase.
Fix suggested by Nathan Froyd.
Fixes: FDO #90302
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Acked-by: "Henry (Yu) Song" <henry.song@samsung.com>
This function tries to use _cairo_xcb_connection_put_image() to do the actual
work. However, that function can only be used for images with "native" stride.
If we only want to upload a rectangle from within an image, the function
_cairo_xcb_connection_put_subimage() has to be used. This function makes sure
that the correct information is sent to the X11 server.
No unit test for this, because we currently do not test the !SHM case
automatically. Perhaps we should?
Signed-off-by: Uli Schlachter <psychon@znc.in>
