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: <ol style="color:rgb(0,0,102)"><li>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? </li><li>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... </li><li>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? </li></ol>Thanks in advance for any feedback/help! Christos. <div class="gmail_quote">On 20 March 2012 12:25, Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk" target="_blank">chris@chris-wilson.co.uk</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, 20 Mar 2012 11:57:58 +0200, Christos Sotiriou <<a href="mailto:csotiriou@gmail.com">csotiriou@gmail.com</a>> wrote: > On 20 March 2012 11:32, Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> wrote: > > > On Tue, 20 Mar 2012 09:42:19 +0200, Christos Sotiriou <<a href="mailto:csotiriou@gmail.com">csotiriou@gmail.com</a>> > > wrote: > > > On 19 March 2012 20:27, Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> 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. </div></div>Yes, drivers are typically crap. <div class="im"> > 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? </div>Which all going well should be before the week is out... <div class="im"> > 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? </div>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. <div class="im"> > > 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? </div>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. <div class="HOEnZb"><div class="h5">-Chris -- Chris Wilson, Intel Open Source Technology Centre </div></div></blockquote></div> -- -------------------------------------------------------------------------- Christos P. Sotiriou email: <a href="mailto:csotiriou@gmail.com">csotiriou@gmail.com</a> Cell: +30 697 8984 222