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>
The RENDER specification requires radial gradients to have the first
circle completely inside the second one, but the error is not actually
generated.
The implementation produces the expected results if either circle
contains the other one, so only fall back in these cases.
The RENDER specification does not specify the constraints on the
gradient stops, but its implementation returns an error if less than 2
stops are used.
Xlib and XCB can work around this because gradients with just one stop
are by-definition the same as gradients with that stop repeated twice.
Fixes radial-gradient-one-stop.
The same code was duplicated (incorrectly and with some minor
differences) in pattern, image, xlib and xcb.
_cairo_gradient_pattern_max_val() abstracts that code in a function
that can be used whenever a gradients extremes need to be rescaled to
fit within a given range.
Fixes huge-linear, huge-radial.
Fixes part of https://bugs.freedesktop.org/show_bug.cgi?id=32215
Xlib, XCB and image use the same code to convert a cairo_matrix_t to a
backend-specific transform.
The code did not handle correctly some matrices, thus a new function
that performs the conversion in a more generic way was added and used
in the backends instead of fixing the repeated code.
Fixes part of https://bugs.freedesktop.org/show_bug.cgi?id=32215
Add the mesh pattern type and an error status to be used to report an
incorrect construction of the pattern.
Update the backends to make them ready to handle the new pattern type,
even if it cannot be created yet.
Remove the hack of using the xlib surface to do glyph rendering and use
the new interface introduced with Qt4.7, or else fallback to image
rendering with freetype.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[2 files changed, 35 insertions(+), 140 deletions(-) \o/]
I did this manually so I could review the docs at the same time.
If anyone finds typos or other mistakes I did, please complain to me (or
better: fix them).
Under the restrictive conditions where we are doing an untransformed
contained upload of an image into a matching surface, perform it in
place. The drivers will attempt to stream such uploads efficiently, far
more so than our code.
Render supports two modes of precision when rendering trapezoids.
Precise specifies points sampling on a 15x17 grid, ala pixman. Imprecise
allows the driver more freedom in the methods used, which may be more
amenable to acceleration. Choose to use the imprecise mode by default,
but still allow users to force the more rigidly specified precision by
changing the antialias mode.
Not only is this useful for users to know which Visual matches any
particular Cairo surface, it should also close a few obscure bugs of not
converting images correctly on upload.
Fixes:
Bug 28492 - cairo_xlib_surface_create_with_xrender_format does not
create visual for resulting surface
https://bugs.freedesktop.org/show_bug.cgi?id=28492
Mozilla Bug 567065 - Try to create offscreen Xlib surface from existing
visual if possible
https://bugzilla.mozilla.org/show_bug.cgi?id=567065
Mozilla Bug 445250 - cairo_draw_with_xlib should provide a non-NULL visual
to callback
https://bugzilla.mozilla.org/show_bug.cgi?id=445250
Reported-by: Oleg Romashin <romaxa@gmail.com>
In the XCopyArea region code, don't modify src_x/y when they are later
used in the unbounded fixup code.
Exposed by composite-integer-translate-source test.
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
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.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=599574
The backend API manipulated the surface prior to checking whether it was
an inert error surface - and in the event of an error surface, tried to
overwrite it's error status.
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.
By preallocating in our data segment a couple of solid patterns for the
stock colours, it becomes more convenient when using those in surface
operations, such as when clearing.
The device is a generic method for accessing the underlying interface
with the native graphics subsystem, typically the X connection or
perhaps the GL context. By exposing a cairo_device_t on a surface and
its various methods we enable finer control over interoperability with
external interactions of the device by applications. The use case in
mind is, for example, a multi-threaded gstreamer which needs to serialise
its own direct access to the device along with Cairo's across many
threads.
Secondly, the cairo_device_t is a unifying API for the mismash of
backend specific methods for controlling creation of surfaces with
explicit devices and a convenient hook for debugging and introspection.
The principal components of the API are the memory management of:
cairo_device_reference(),
cairo_device_finish() and
cairo_device_destroy();
along with a pair of routines for serialising interaction:
cairo_device_acquire() and
cairo_device_release()
and a method to flush any outstanding accesses:
cairo_device_flush().
The device for a particular surface may be retrieved using:
cairo_surface_get_device().
The device returned is owned by the surface.
When the reference point was tirggering _line_exceeds_16_16() and got
adjusted, the code failed to compute the srcX and srcY arguments for the
call to XRenderCompositeTrapezoids() correctly and caused the resulting
source image to be misaligned.
Within our code base we carried a few hacks to utilize the component
alpha capabilities of pixman, whilst not supporting the concept for our
own masks. Thus we were setting it upon the pixman_image_t that we
passed around through code that was blissfully unaware and indeed the
component-alpha property was forgotten (e.g. upgrading glyph masks).
The real issue is that without explicit support that a pattern carries
subpixel masking information, that information is lost when using that
pattern with composite. Again we can look at the example of compositing
a sub-pixel glyph mask onto a remote xlib surface for further failure.
Gah, that was a horrible mistake. It was a flawed hack to create Pixmaps
of the correct depth when cloning patterns for blitting to the xlib
backend. However, it had the nasty side-effect of discarding alpha when
targeting Window surfaces. The correct solution is to simply correct the
Pixmap of the desired depth and render a matching pattern onto the
surface - i.e. a reversal the current acquire -> clone. See the
forthcoming revised xcb backend on how I should have done it originally.
