Initialising 'display' to NULL and checking before deferencing during display->base.
This patch will check the deferencing of uninitialised 'display' in case,
_cairo_xlib_display_acquire does not return CAIRO_STATUS_SUCCESS.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=87893
Signed-off-by: Arpit Jain <jain.arpit@samsung.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
malloc(0) needn't return NULL, and on glibc, doesn't. Then we encounter
a loop of the form do { ... } while (--c), which doesn't do quite what
you were hoping for when c is initially 0.
Since there's nothing to swap in this case, just bomb out.
Signed-off-by: Adam Jackson <ajax@redhat.com>
The elts offset is a delta from the previous glyph coordinate. So by
subtracting the dst origin everytime, we were accumulating a glyph
position error. Instead we just want to offset the starting coordinate
and then always use relative positions.
Reported-by: Theo Veenker <T.J.G.Veenker@uu.nl>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Initialise shm during its declaration so that it is indeed initialised
for the cleanup after every path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Make sure that we simply copy from the SHM segment into the target
drawable, and not inadvertently stage it through another SHM buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the image is already inside a SHM segment, but the image format does
not match the surface, fallback to the XRender paths in order to perform
colorspace conversion on the data already inside the Xserver.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Along the draw_image_boxes() upload path, we were actually marking the
ShmPixmap as still active for the subsequent drawing operation - which
could in theory never be submitted...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Remember to check for a supported render version before making a
FillRectangle request, and fallback to the core protocol where possible
instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Before rendering into the mask, we should first check whether the
subsequent call to composite the mask will trigger a fallback. In that
case, we should fallback earlier and do the operation in place.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So that we can specify the entire source surface as the region to copy
and not introduce clipping errors.
Fixes regression from
commit c068691ff5
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Aug 17 21:33:54 2012 +0100
xlib/shm: Use an impromptu upload ShmSegment
Reported-by: John Lindgren <john.lindgren@aol.com>
Reported-by: Kalev Lember <kalevlember@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56547
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reduce the number of copies required for uploading large image data.
Ultimately we want the client to allocate the similar-image itself to
acheive zero copy, this is just an intermediate step for legacy clients.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
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>
Rather than compress the copies into a clip + copy, iterate over and
perform each copy separately so as to avoid the confusion for
window-to-window copies and the solitary GC->pCompositeClip.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
cairo-xlib semantics state that we copy the contents of a Window's
children when we use a Window as a source in a cairo operation. This
requires that we set the IncludeInferiors SubwindowMode on the GC.
However, we can only set one SubwindowMode for an operation and our
semantics are that drawing performed by cairo onto a Window are clipped
by its children (the ClipByChildren SubwindowMode). Therefore if we have
to copy between two Window, we can not use CopyArea. Furthermore, we
cannot tell if an external Drawable is a Window or a Pixmap, therefore
we treat all foriegn Drawables as Window.
Failure here means falling back to a render path, where we can
independently control the subwindow mode on the source and destination,
or to a GetImage/PutImage if the xserver does not support render.
Reported-by: Benjamin Otte <otte@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
None of the cairo clipping computations guarantee that the resulting
list of rectangles are constructed in any particular order. Promising
that they are results in an X error (BadMatch) which generally causes
applications to crash.
I suspect this may well be implicated in many (many) bug reports about
applications which use cairo.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having spent the last dev cycle looking at how we could specialize the
compositors for various backends, we once again look for the
commonalities in order to reduce the duplication. In part this is
motivated by the idea that spans is a good interface for both the
existent GL backend and pixman, and so they deserve a dedicated
compositor. xcb/xlib target an identical rendering system and so they
should be using the same compositor, and it should be possible to run
that same compositor locally against pixman to generate reference tests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
P.S. This brings massive upheaval (read breakage) I've tried delaying in
order to fix as many things as possible but now this one patch does far,
far, far too much. Apologies in advance for breaking your favourite
backend, but trust me in that the end result will be much better. :)
