Re: GTK+, Cairo, XLib integration for fast 2D graphics drawing

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);
    visual =
   gdk_x11_visual_get_xvisual(gtk_widget_get_visual(GTK_WIDGET(maincanvas)));

    maincanvas_sf = cairo_xlib_surface_create(xdisplay, xid, visual,
   maincanvasWidth, maincanvasHeight);
    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
   properly?

Thanks in advance for any feedback/help!

Christos.

On 20 March 2012 12:25, Chris Wilson <[email protected]> wrote:

> On Tue, 20 Mar 2012 11:57:58 +0200, Christos Sotiriou <[email protected]>
> wrote:
> > On 20 March 2012 11:32, Chris Wilson <[email protected]> wrote:
> >
> > > On Tue, 20 Mar 2012 09:42:19 +0200, Christos Sotiriou <
> [email protected]>
> > > wrote:
> > > > On 19 March 2012 20:27, Chris Wilson <[email protected]>
> wrote:
> > > > > The truly puzzling part for me is that they seem viable candidates
> to
> > > > > hit the fast-paths, yet end up in the general polygon code.
> > > > >
> > > > >  << /content //COLOR_ALPHA /width 500 /height 500 >> surface
> context
> > > > > 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
> explain
> > > > > 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;
> would
> > > > 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
> Cairo
> > 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
> cairo_pattern_set_matrix().
>
> Although I'm not going to recommend doing a 10x down-scaling.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>



-- 
--------------------------------------------------------------------------
Christos P. Sotiriou
email: [email protected]
Cell: +30 697 8984 222

-- 
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo