<div class="gmail_quote">On 20 March 2012 11:32, Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">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="im">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: </div><div class="im">> > 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? </div>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. </blockquote></div> 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. 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? 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? 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? -- -------------------------------------------------------------------------- Christos P. Sotiriou email: <a href="mailto:csotiriou@gmail.com">csotiriou@gmail.com</a> Cell: +30 697 8984 222