[cairo] GTK+, Cairo, XLib integration for fast 2D graphics drawing

[Chris Wilson]

On Tue, 20 Mar 2012 11:57:58 +0200, Christos Sotiriou <csotiriou at gmail.com> wrote:
> 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> 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