[cairo] X11 v. XQuartz
Bryce W. Harrington
b.harrington at samsung.com
Wed Nov 6 21:01:57 CET 2013
I've not used those calls myself, but referring to the source code
* @cr: a cairo context
* Temporarily redirects drawing to an intermediate surface known as a
* group. The redirection lasts until the group is completed by a call
* to cairo_pop_group() or cairo_pop_group_to_source(). These calls
* provide the result of any drawing to the group as a pattern,
* (either as an explicit object, or set as the source pattern).
* This group functionality can be convenient for performing
* intermediate compositing. One common use of a group is to render
* objects as opaque within the group, (so that they occlude each
* other), and then blend the result with translucence onto the
Essentially, the API lets you set up a temporary cairo_surface_t and
cairo_t, do your drawing in it, then clean them up afterwards.
It looks like it's possible to have backend-specific
push_group/pop_group implementations, but I'm not seeing any examples,
so guess it always uses the default implementation. In this
implementation, it makes a call to create a surface. Depending on the
clipping and extents, this could be cairo_image_surface_create(),
cairo_recording_surface_create(), or _cairo_surface_create_scratch().
So, it does use some memory for this, although it's released immediately
after. Also, at least with the image surface, I'm gathering it forces
software rendering. That may be why it "solves" your bug - it moves
your drawing operation out of XQuartz and does it in software. So might
incur some performance impact there. The actual impacts of all of this
probably depend on the drawing operation in question.
Maybe the best solution would be to convince Jeremy to backport his fix
to the 1.11 xserver for the earlier XQuartz release(s)? I'm not
familiar with XQuartz so don't know what their policies/procedures are
for stable release updates.
Anyway, hope this gives helps.
On Mon, Nov 04, 2013 at 09:00:01AM -0500, Jennifer Adams wrote:
> Second follow up:
> I am happy to report that yesterday's release of XQuartz-2.7.2_rc4 contains a fix that resolves this problem. The clues were in http://xquartz.macosforge.org/trac/ticket/525 and it appears the bug was almost three years old, introduced with a patch to xorg-server-1.11 called "Move miTrapezoids() into fb as fbTrapezoids()". About 9 months ago, a user (who happens to be a developer of another visualization tool for meterological data) posted a cairo "fix" that overcame this bug in XQuartz -- surround all drawing commands with cairo_push()/cairo_pop_to_source() calls. I had an email exchange with this user, and we were a little wary of the fix because neither of us could say exactly why it worked, or what the memory use implications would be. Can anyone here explain what the costs and benefits are for the push/pop operation, and what is going on under the hood with X11 when it is used? The answer is relevant for our users who are using broken versions of XQuartz.
> On Aug 8, 2013, at 2:00 PM, Jennifer Adams wrote:
> > Follow up:
> > I wrote a short C program to demonstrate the problem. It works with X11, and reliably fails with XQuartz (the rendering is incomplete). I realize this is probably an issue for the XQuartz folks, but before I go there, it would be nice to rule out incorrect Cairo code. The results are the same whether I compile and run my demo on my laptop or on a remote linux server that I connect to using ssh. I updated the images in the links given in my first message.
> > --Jennifer
> > On Aug 6, 2013, at 5:13 PM, Jennifer Adams wrote:
> >> Dear Experts,
> >> I am a developer of GrADS, a visualization tool for meteorological data. GrADS uses X11 for its interactive display window, but it also has a batch mode, so you can create graphics without the use of X. We have developed an interface for Cairo to do the rendering, not only to the X window, but also to create png, ps, eps, pdf, and svg output.
> >> The problem I am having is with the X rendering when using XQuartz. Everything looks right when I use the old (deprecated) X11 application on my Mac, but if I use XQuartz, I get an incomplete rendering, illustrated by two screen shots (links are given below.) The graphical elements are very basic, these plots contain nothing but line segments and filled rectangles.
> >> http://iges.org/jma/x11.png
> >> http://iges.org/jma/xquartz.png
> >> The batch-mode renderings by Cairo are correct, and the non-Cairo version of GrADS does not exhibit the problem with the X window display, so I am pretty sure that Cairo and XQuartz are not playing well together.
> >> I am running Mac OS X 10.7.5. When running the old X11 application, the version information in the "About X11" window says: XQuartz 2.6.5 (xorg-server 1.10.6). When running XQuartz, the version numbers are more recent: XQuartz 2.7.4 (xorg-server 1.13.0). The Cairo version is 1.12.8.
> >> I searched through my 2-yr archive of forum emails and found nothing related to rendering problems with XQuartz. Any suggestions or ideas about what might be going wrong would be most welcome.
> >> --Jennifer
> >> --
> >> Jennifer M. Adams
> >> Center for Ocean-Land-Atmosphere Studies (COLA)
> >> 111 Research Hall, Mail Stop 2B3
> >> George Mason University
> >> 4400 University Drive
> >> Fairfax, VA 22030
> >> --
> >> cairo mailing list
> >> cairo at cairographics.org
> >> http://lists.cairographics.org/mailman/listinfo/cairo
> > --
> > Jennifer M. Adams
> > Center for Ocean-Land-Atmosphere Studies (COLA)
> > 111 Research Hall, Mail Stop 2B3
> > George Mason University
> > 4400 University Drive
> > Fairfax, VA 22030
> > --
> > cairo mailing list
> > cairo at cairographics.org
> > http://lists.cairographics.org/mailman/listinfo/cairo
> Jennifer M. Adams
> Center for Ocean-Land-Atmosphere Studies (COLA)
> 111 Research Hall, Mail Stop 2B3
> George Mason University
> 4400 University Drive
> Fairfax, VA 22030
> cairo mailing list
> cairo at cairographics.org
More information about the cairo