_cairo_clip_init_copy() was removed with commit b132fae5e8,
but a few calls were still remaining.
Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weigelt@gr13.net>
Signed-off-by: Uli Schlachter <psychon@znc.in>
We have two places where copying from box set to clip is
implemented in the same way. Just move that to one function.
Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weigelt@gr13.net>
Signed-off-by: Uli Schlachter <psychon@znc.in>
When parameter force_allocation is false *and* the box set has
exactly one chunk, this chunk is returned directly - w/o copying it.
That mode is never used, and it's highly problematic as it's unclear
whether we have to free the returnd object or it's still owned
by somebody else.
Just dropping the useless parameter / corner case to make the function
simpler and more robust.
Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weigelt@gr13.net>
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code correct, but the compiler can't check that and thinks
there're uninitialized variables.
Perhaps we could rewrite it in a better way, so the compiler
can do better (even arch specific) optimizations.
Signed-off-by: Enrico Weigelt, metux IT consult <enrico.weigelt@gr13.net>
Signed-off-by: Uli Schlachter <psychon@znc.in>
If XShmGetImage() fails, the code tries to continue with its normal,
non-shared-memory path. However, the image variable, which was previously set to
NULL, now points to an already-destroyed surface, causing a double-free when the
function cleans up after itself (actually, its an assertion failure because the
reference count of the surface is zero, but technically this is still a double
free).
Fix this by setting image=NULL after destroying the surface that this refers to,
to make sure this surface will not be destroyed again.
While we are here (multiple changes in a single commit are bad...), also fix the
cleanup done in bail. In practice, &image->base should be safe when image==NULL,
because this just adds some offset to the pointer (the offset here is actually
zero, so this doesn't do anything at all). However, the C standard does not
require this to be safe, so let's handle this case specially.
Note that anything that is fixed by this change is still buggy, because the only
reason why XShmGetImage() could fail would be BadDrawable, meaning that the
target we draw to does not exist or was already destroyed. This patch will
likely just cause X11 errors elsewhere and drawing to (possible) invalid
drawables is not supported by cairo anyway. This means that if SHM fails, the
following fallback code has a high chance of failing, too.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91967
Signed-off-by: Uli Schlachter <psychon@znc.in>
When an unbounded recording surface is used multiple times with
different extents for each operation we need the XObject containing
the recording surface to have the same origin for each operation. This
is not possible when the recording surface is converted to PDF
coordinates because each operation has different extents resulting in
a different origin when the Y-axis is flipped (since the flip matrix
depends on the recording surface height which for unbounded surfaces
depends on the extents of the operation that paints the recording
surface).
Switching to cairo coordinates by emitting a Y-axis flip matrix as the
first object of each page allows the recording surface to be emitted
in cairo coordinates. This results in the same origin for all
operations using the recording surface XObject.
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>
