[cairo] [PATCH] Proposed change _cairo_composite_rectangles_init
Christophe de Dinechin
christophe at taodyne.com
Mon Mar 8 08:38:57 PST 2010
As part of my effort to render directly on an OpenGL surface while preserving the native coordinate systems, I noticed that Cairo implicitly clips negative coordinates, even when the device coordinate space says otherwise. Specifically, _cairo_composite_init_rectangles receives only the surface width and height as input, and creates the 'unbounded' rectangle as (0,0,width,height). It ignores the actual rectangle returned by the device get_extents(), and only uses the width and height. There's also an assert should the device indicate that its extents is unbounded.
For OpenGL rendering, this is all highly undesirable, as it is relatively frequent for the native OpenGL coordinate space to allow negative values, e.g. (0,0) might be in the center of the OpenGL surface. Furthermore, the OpenGL coordinate space is unbounded,. So an OpenGL surface that is not a framebuffer created specifically to represent a Cairo surface should be considered unbounded.
In order to minimize disruption of the interface of the _cairo_composite_init_rectangles family, I propose to leave it as is, but to allow negative surface_width and surface_height input parameters, in which case the extents unbounded rectangle is to be given by the caller (typically, the device's get_extents function). This is what the attached patch set does (along with a little context).
Since I'm new to Cairo or the OpenGL back-end, what I'm suggesting might be bad taste. One thing in particular I'm not sure about is whether I was right to leverage the existence of a Cairo framebuffer (the surface->fb field) to indicate if I'm rendering to a Cairo or "native" OpenGL surface. Right now, if surface->fb==0, device clipping is off and the back-end attempts to save and restore things like the OpenGL projection matrix, whereas if surface->fb is set, device clipping occurs as before and the projection matrix is set to match normal Cairo coordinates. It might be better to add a flag in the OpenGL surface specifically for that purpose, but I couldn't think of any use case.
I'm afraid that this patch set adds a few regressions, but I have trouble testing. On MacOSX, make test doesn't compile with an OpenGL back-end at all. On Linux (we tried Fedora and Ubuntu running in VMware), "make test" on git master crashes the X server before completion, and there is an impressive number of FAIL and CRASHED reports. Will I get better results outside of VMware? Any help with the "normal" testing methodology is welcome.
Thanks for your feedback
Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-problem-with-NULL-CG-context-for-empty-surface.patch
Type: application/octet-stream
Size: 1885 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20100308/ed0271ba/attachment-0008.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Added-a-function-to-use-the-current-GL-context-direc.patch
Type: application/octet-stream
Size: 2728 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20100308/ed0271ba/attachment-0009.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Immediate-rendering-when-using-cairo_gl_surface_crea.patch
Type: application/octet-stream
Size: 4005 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20100308/ed0271ba/attachment-0010.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Preserve-the-GL-matrix-when-working-on-screen.patch
Type: application/octet-stream
Size: 3665 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20100308/ed0271ba/attachment-0011.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-Use-linear-texture-interpolation-and-avoid-useless-c.patch
Type: application/octet-stream
Size: 1775 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20100308/ed0271ba/attachment-0012.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-Fix-warning-about-use-of-possibly-uninitialized-vari.patch
Type: application/octet-stream
Size: 805 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20100308/ed0271ba/attachment-0013.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007-Avoid-clipping-negative-coordinates-for-devices-with.patch
Type: application/octet-stream
Size: 5507 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20100308/ed0271ba/attachment-0014.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0008-Allow-negative-coordinates-in-OpenGL-surfaces.patch
Type: application/octet-stream
Size: 1289 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20100308/ed0271ba/attachment-0015.obj>
More information about the cairo
mailing list