IGT wants to add support for planes with a bit depth >10, which
requires a higher precision format than we have currently.
I'm using RGBA as format, because of its existence in OpenGL.
With the new formats we can directly convert our bytes to half float,
or multiply a colro vector with a matrix to go to the Y'CbCr colorspace.
This requires pixman 0.36.0, so bump the version requirement.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
_cairo_malloc(0) always returns NULL, but has not been used
consistently. This patch replaces many calls to malloc() with
_cairo_malloc().
Fixes: fdo# 101547
CVE: CVE-2017-9814 Heap buffer overflow at cairo-truetype-subset.c:1299
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Remove the debug hack from
commit f337342c88
Author: Bill Spitzak <spitzak@gmail.com>
Date: Fri Jul 18 18:46:26 2014 -0700
V6 image: Use convolution filters for sample reconstruction when downscaling
as it forces the fallback image surface for xlib causing severe
performance degradation.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82002
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Bill Spitzak <spitzak@gmail.com>
Cc: Bryce Harrington <b.harrington@samsung.com>
This version removes testing code and has some changes to match my current
pixman version. My proposed pixman patch (not finished yet) will produce
exactly the same results as this cairo patch.
This code contains an all-new filter generator to replace the one that is
in pixman. Results in 222 pass/298 failed image tests, which is much better
than the previous versions of this patch.
Filter generator (which should probably be in pixman):
- Single filter, no "reconstruction" and "sample" filter
- Filters for derivative < 1 work
- Fixed IMPULSE and BOX
- Added TENT, CATMULL_ROM, NOTCH. Remove LANZCOS2.
- Renamed CUBIC to MITCHELL
Cairo's filter settings:
- CAIRO_FILTER_GOOD: uses BOX filter for scales less than .75 in either
direction. Uses PIXMAN_FILTER_GOOD (ie BILINEAR) otherwise.
- CAIRO_FILTER_BEST: uses CATMULL filter always. Upscaling more than 2x will
produce anti-aliased square pixels, similar to OS/X.
- CAIRO_FILTER_GAUSSIAN: this obsolete value is used to test other filters.
The program must declare and poke the filter into the static varialbe
ikernel. This should be removed for production code.
NYI: This version uses the fallback for xlib always. The xlib and xcb backends
must be rewritten to use the fallback version if filtering is needed. Or the
filtering code must be moved to XRender.
This reverts commit 09a2b2ed31.
Back in 2009, _cairo_xlib_display_get_xrender_format() had to acquire a lock to
do its job. The above commit added a fast-path which avoided the lock in most
cases.
However, in 2010 commit f74ad37e66 modified the
locking in the cairo-xlib backend and now this function never takes any locks.
Thus, the fast-path that was added a year earlier now just does the same thing
that the regular code does and the list of cached formats was checked twice.
Reverting the earlier commit fixes this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The 'count' parameter is an indication to libXrender of the number of
matches to skip before reporting (rather than a limit on the number to
report). As we only want the first match, always pass 0.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Martin Husemann reported that on his NetBSD machine the vendor was being
reported as "The Xorg Foundation", a non-conformist separatist split of
the Peoples' Liberation Army^W^W^W "The X.Org Foundation". Simply check
for both during initialisation.
Reported-by: Martin Husemann <martin@duskware.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we may utilize X extensions as we shutdown and release resources
during CloseDisplay, we need to run our own callback first. If we run
last, than we reinstantiate the extensions which often have the
unfortunate habit of then persisting with stale data across the next
Display connection, causing invalid requests to be generated and raise
XErrors.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Flushing the shm operation is a fairly rare event, as it is typically
only involved with mixed rendering on a similar image, and should be
triggering its own events. Therefore we should be able to reduce our
event emission to the critical points in order to limit the amount of
extra overhead we generate.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the XCheckWindowEvent() has the unwanted side-effect of flushing the
output queue when there is no event available (libX11 seems to be
entirely anti-performant), we need to roll our own that only checks the
already available event queue.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Adding lots of requests without popping the replies causes xcb to
continually sort large lists of unprocessed data. Use an event instead
and regularly dequeue them.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Make sure that we always detach the ShmSegments upon dispose, or else we
can trivially leak lots of memory when using serial Display connections.
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>
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>
The documentation was apparently copied from
cairo_xcb_device_debug_cap_xrender_version without changing "XCB" into "Xlib".
Signed-off-by: Uli Schlachter <psychon@znc.in>
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. :)
This adds checks for NULL pointers, devices in an error state and devices which
aren't owned by the right backend.
Signed-off-by: Uli Schlachter <psychon@znc.in>
In order to defer the pixel conversion till as late in the pipeline as
possible, we want to try and preserve the pixman image format whilst
uploading the pixel data. To do this, we want to create an XRender
surface with a matching PictFormat to the source image. Then we need to
make sure we take the quick path through _draw_image_surface for none
and direct conversions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
45665c0d48 breaks the build of
cairo-xlib-xcb because it does not disable the compilation of
cairo-xlib implementation files when cairo-xlib-xcb is enable. This
results in collisions when linking.
Reported-by: James Cloos <cloos@jhcloos.com>
Introduce cairo_xlib_device_debug_set_precision() to override the
automatic selection of rendering precision and force the Xorg/DDX to
strictly adhere to the precise rendering mode of the Render
specification. This allows us to test drivers without worrying, too
much, about minor discrepancies in antialiasing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is a common format used by framebuffers to drive 10bpc displays
and is often hardware accelerated by XRender with underlying support
from pixman's x2r10g10b10 format (which provides coercion paths for
fallbacks).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The cairo-freelist-private.h header has a number of static inline
functions which call hidden functions in libcairo. This poses
a problem on Solaris where the native compiler compiles inline
functions whether they are used or not, thereby adding the
link time requirements on hidden functions from whatever code
that includes cairo-freelist-private.h. Unfortunately the
boilerplate code includes cairo-private headers and indirectly
the freelist header, so linking the boilerplate helper library
fails on Solaris.
This patch separates the structure definitions from the function
prototypes and static inlines in cairo-freelist-private.h by moving
the datatypes to a new cairo-freelist-type-private.h.
I updated the Free Software Foundation address using the following script.
for i in $(git grep Temple | cut -d: -f1 )
do
sed -e 's/59 Temple Place[, -]* Suite 330, Boston, MA *02111-1307[, ]* USA/51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA/' -i "$i"
done
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=21356
Add a _cairo_xlib_device_create() function that could easily be exported
as a replacement for _cairo_xlib_display_get(). This function returns a
cairo_device_t instead of a cairo_xlib_display_t because the display
isn't acquired.
Do not call the destroy function directly, but rely on the reference
counting to call the notifier upon the last reference. Instead, simply
release the reference we were holding for the cache and CloseDisplay
callback.
The code now uses the locking of the cairo_device_t instead of its own
mutexes.
The code was modified so that cairo_surface_t does no longer reference
the display directly. Instead, it calls _cairo_xlib_display_acquire().
If a function assumes an already acquired display, it now requires the
caller to provide a cairo_xlib_display_t parameter. Functions that do
not require an acquired display will not require the display parameter
or they will take the cairo_device_t instead.
We were exposing the actual value of CAIRO_FORMAT_INVALID
through API functions already, so it makes sense to just
go ahead and put it in the cairo_format_t enum.
If the XServer claims to support the required Render extension then send
it the operations. However for the cases where we know it does not work,
i.e. the current and previous generations (<=1.6) of Xorg servers, enable
the buggy_pad_reflect fallbacks.
The issue Joonas was trying to solve was the unwanted inclusion of
the inlines via cairo-freelist-private.h. Unwittingly he included
cairoint.h from cairo-xlib-private.h instead, a far more heinous crime as
that causes the boilerplate to try to use the hidden, private symbols.
Instead we resolve this issue by making the cairo_xlib_display_t structure
private to cairo-xlib-display.c and provide functions to manipulate the
abstract data type. Whilst in the vicinity, we rename
cairo_xlib_screen_info_t to cairo_xlib_screen_t for consistency and
cleanliness.
This patch revises xlib so that it doesn't depend on having recent
Xrender headers to build. In particular, some definitions were added
to the private xrender header file, and an ifdef render version check
CAIRO_SURFACE_RENDER_SUPPORTS_OPERATOR was changed to a run-time
check using CAIRO_SURFACE_RENDER_HAS_PDF_OPERATORS.
We can offload creation of gradients to server that support RENDER 0.10
and later. This greatly reduces the amount of traffic we need to send over
our display connection as the gradient patterns are much smaller than the
full image. Even if the server fallbacks to using pixman, performance
should be improved by the reduced transport overhead. Furthermore this is a
requisite to enable hardware accelerated gradients with the xlib backend.
Running cairo-perf-trace on tiny, Celeron/i915:
before: firefox-20090601 211.585
after: firefox-20090601 270.939
and on tiger, CoreDuo/nvidia:
before: firefox-20090601 70.143
after: firefox-20090601 87.326
where linear gradients are used extensively throughout the GTK+ theme.
Not quite the result I was expecting!
In particular, looking at tiny:
xlib-rgba paint-with-alpha_linear-rgba_over-512 47.11 (47.16 0.05%) -> 123.42 (123.72 0.13%): 2.62x slowdown
█▋
xlib-rgba paint-with-alpha_linear3-rgba_over-512 47.27 (47.32 0.04%) -> 123.78 (124.04 0.13%): 2.62x slowdown
█▋
xlib-rgba paint-with-alpha_linear-rgb_over-512 47.19 (47.21 0.02%) -> 123.37 (123.70 0.13%): 2.61x slowdown
█▋
xlib-rgba paint-with-alpha_linear3-rgb_over-512 47.30 (47.31 0.04%) -> 123.52 (123.62 0.09%): 2.61x slowdown
█▋
xlib-rgba paint_linear3-rgb_over-512 47.29 (47.32 0.05%) -> 118.95 (119.60 0.29%): 2.52x slowdown
█▌
xlib-rgba paint_linear-rgba_over-512 47.14 (47.17 0.06%) -> 116.76 (117.06 0.16%): 2.48x slowdown
█▌
xlib-rgba paint_linear3-rgba_over-512 47.32 (47.34 0.04%) -> 116.85 (116.98 0.05%): 2.47x slowdown
█▌
xlib-rgba paint_linear-rgb_over-512 47.15 (47.19 0.03%) -> 114.08 (114.55 0.20%): 2.42x slowdown
█▍
xlib-rgba paint-with-alpha_radial-rgb_over-512 117.25 (119.43 1.21%) -> 194.36 (194.73 0.09%): 1.66x slowdown
▋
xlib-rgba paint-with-alpha_radial-rgba_over-512 117.22 (117.26 0.02%) -> 193.81 (194.17 0.11%): 1.65x slowdown
▋
xlib-rgba paint_radial-rgba_over-512 117.23 (117.26 0.02%) -> 186.35 (186.41 0.03%): 1.59x slowdown
▋
xlib-rgba paint_radial-rgb_over-512 117.23 (117.27 0.02%) -> 184.14 (184.62 1.51%): 1.57x slowdown
▋
Before 1.10, we may choose to disable server-side gradients for the
current crop of Xorg servers, similar to the extended repeat modes.
[Updated by Chris Wilson. All bugs are his.]
If we know the CPU can read pointers atomically, then we can simply peek
into the cached_xrender_formats to see if we already have a match, before
taking the mutex. (Acquiring the mutex here is a minor nuisance that
appears on the callgrind profiles.)
Optimistically check to see if there is any outstanding work before
checking under the mutex. We don't care if we occasionally do not run the
queue this time due to contention, since we will most likely check again
very shortly or clean up with the display.
Most drivers and the X server used to have incorrect RepeatPad/RepeatReflect
implementations, forcing cairo to fall back to client-side software rendering,
which is painfully slow due to pixmaps being transfered over the wire. These
issues are mostly fixed in the drivers (with the exception of radeonhd, whose
developers didn't respond) and the RepeatPad software fallback is implemented
correctly as of pixman-0.15.0, so this patch will hand off composite operations
with EXTEND_PAD/EXTEND_REFLECT source patterns to XRender.
There is no way to detect whether the X server or the drivers use a
broken Render implementation, we make a guess based on the server
version: It's probably safe to assume that 1.7 X servers will use
fixed drivers and a recent enough version of pixman.
