[cairo] GTK+, Cairo, XLib integration for fast 2D graphics drawing
csotiriou at gmail.com
Tue Oct 9 23:20:40 PDT 2012
Dear Chris, Dear Cairo Developers/Users,
I had a few more questions regarding my older post, *i.e.* being able to
draw millions of small rectangles on a Cairo surface provided by GTK/GDK.
Chris Wilson was kind enough to explain that my Cairo drawing is slow as I
use a non-integer, non-uniform scaling factor, and has improved the Cairo
code for new releases; however, I am stuck with the older Cairo version
which I mention in my older email (for O/S compatibility), so I am back to
probing this issue further, as I really need to speed up zoom-in/zoom-out
for my rectangles.
My two questions are the following:
1. Does Cairo *always use or not use* 2D Hardware Rendering? How can
this be enabled or verified using Cairo code? If not, where can I find a
Cairo code snippet which enables X acceleration?
2. As I mention in a prior message I used two methods for
"double-buffering", drawing to an image surface OR drawing to a similar
surface (cairo_surface_create_similar). Funnily enough, the latter was
faster. Is there a reason for this? It seems mysterious...
3. Related to my first question, I tried to use Cairo/X interaction to
verify if this would improve drawing, *i.e.* if I used an Xlib surface.
I used the following code:
xdisplay = gdk_x11_drawable_get_xdisplay(maincanvas_drawable);
xid = gdk_x11_drawable_get_xid(maincanvas_drawable);
maincanvas_sf = cairo_xlib_surface_create(xdisplay, xid, visual,
maincanvas_cs = cairo_create(maincanvas_sf);
However, drawing to the Xlib surface did not help either (actually made
matters worse, as GDK/GTK interaction with scrollbars stopped working). So,
coming back to my first question, how can I guarantee 2D acceleration and
why is an Xlib surface not helping? How can an Xlib surface be used
Thanks in advance for any feedback/help!
On 20 March 2012 12:25, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Tue, 20 Mar 2012 11:57:58 +0200, Christos Sotiriou <csotiriou at gmail.com>
> > On 20 March 2012 11:32, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > On Tue, 20 Mar 2012 09:42:19 +0200, Christos Sotiriou <
> csotiriou at gmail.com>
> > > wrote:
> > > > On 19 March 2012 20:27, Chris Wilson <chris at chris-wilson.co.uk>
> > > > > The truly puzzling part for me is that they seem viable candidates
> > > > > hit the fast-paths, yet end up in the general polygon code.
> > > > >
> > > > > << /content //COLOR_ALPHA /width 500 /height 500 >> surface
> > > > > n 22.726562 22.726562 454.546875 454.546875 rectangle
> > > > > 0 0.65 1 rgb set-source
> > > > > 0.295602 0.913843 scale
> > > > > 3.655372 set-line-width
> > > > > stroke+
> > > > > pop
> > > > >
> > > > > Oh, I see. A non-uniform, non-integer scale factor. That would
> > > > > it. Let's see if I can cook up something faster for you.
> > > > >
> > > >
> > > > I can round the scaling factor for the cairo_scale() function call;
> > > > that make a big performance difference?
> > >
> > > I've already fixed the fast-path to catch this case as well. The other
> > > thing worth asking about is that in the trace you use an image surface
> > > for your rendering. Is this a deliberate change from earlier? For the
> > > rendering you are performing, with a good driver, all the overhead will
> > > be in cairo converting the strokes into geometry, though I suspect
> > > the transfer of the image will be smaller than all the geometry. With
> > > cairo-1.12, you may like to use cairo_surface_create_similar_image()
> > > instead, as that opens up the possibilities of doing zero-copy uploads.
> > >
> > I tried two approaches for "double-buffering",
> > (1) using an image surface,
> > (2) using cairo_surface_create_similar(), as I read in the mailing lists,
> > that it achieved better performance.
> > I actually found that (1) is faster, surprisingly enough! This is what
> > worried me in the first place with respect to 2D performance.
> Yes, drivers are typically crap.
> > When you say that "you already fixed the fast-path to catch this case as
> > well", I guess you mean that this change will be included in the next
> > version, correct?
> Which all going well should be before the week is out...
> > Hence, for the current version I guess the only suggestion for increasing
> > performance, based on my existing cairo rendering implementation, is to
> > round the scaling to an integer, is that right?
> Not sufficient sorry. The fast rectilinear stroking path was limited to no
> scaling in those versions. This is one area where cairo-1.12 has made
> significant improvements.
> > Thanks again for your time,
> > Christos.
> > P.S. a quick and related question on suface copying for increasing
> > performance - if I draw on a large image surface, say 2000x2000, and then
> > use cairo_set_source_surface() to copy this surface to a smaller one, say
> > 200x200, is the expected behaviour for cairo_set_source_surface() to
> > automatically shrink and map the original image (map) to the target,
> > smaller surface?
> No, you have to specify the pattern transformation yourself. Normally it
> is taken from the current transformation matrix at the time of setting
> the source, with the pattern transform itself remaining identity.
> Howerver, you can also set a transformation on the pattern itself using
> Although I'm not going to recommend doing a 10x down-scaling.
> Chris Wilson, Intel Open Source Technology Centre
Christos P. Sotiriou
email: csotiriou at gmail.com
Cell: +30 697 8984 222
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cairo