[cairo] GTK+, Cairo, XLib integration for fast 2D graphics drawing
csotiriou at gmail.com
Tue Mar 20 02:57:58 PDT 2012
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>
> > On 19 March 2012 20:27, Chris Wilson <chris at chris-wilson.co.uk> 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.
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
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,
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,
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