[cairo] Cool stuff

[Chris Wilson]

Excerpts from Behdad Esfahbod's message of Tue Sep 01 00:43:32 +0100 2009:
> Thanks Chris,
> 
> Comments inline.  Far far from exhaustive.  Just can't go over it all in a day 
> or a week!

All comments appreciated - thanks!
 
> On 08/31/2009 05:32 AM, Chris Wilson wrote:
> >
> > A couple of the more superficial changes first:
> >   * The skia backend. This is an update of Vlad's backend to pass
> >     everything that we can to Skia to use natively. It requires a
> >     recent build of skia and '--enable-skia --with-skia=/path/to/skia/'
> >     passed to configure. Like the qt backend this allows us to sanity
> >     check our code-paths, and my impression was that it was quite
> >     favourable towards cairo -- though I did not spend any time ensuring
> >     I had built Skia correctly for my system.
> 
> So, I'm totally clueless...  Can skia become an alternative to pixman for 
> cairo?  Or it's totally a different thing?  Same question about Qt.

At the current level of functionality, skia is an inadequate replacement
for pixman. My primarily purpose in pushing the backend is that some
operations it does do outperform pixman and cairo. For many others,
cairo/pixman is much faster. Thus it is a useful tool to highlight our
own weaknesses.

Qt is a different story, as for some systems it may be the only windowing
system available. Besides which it too provides a useful comparison of
our performance.

> >   * The Tee surface. This is a simple surface that has been talked about
> >     for some time, but without any pressing need for its inclusion. The
> >     idea (which hopefully I've remembered correctly from Behdad's
> >     outline) is that the tee uses a single master surface for which any
> >     query on the surface is redirected and one or more slaves. All
> >     drawing operations are then sent to both the master and all the
> >     slaves. (This was made significantly easy by making the clip part of
> >     the explicit drawing operation.) Essentially this allows us to clone
> >     the output to multiple different surface - initially used only for
> >     logging/recording purposes.
> 
> Yes, it looks very close to what I expected.  Since this is a small bit I 
> easily understand, lemme review it here:
 
[snip, suggestions on how to improve the function naming are good]
 
> To the implementation.  I personally prefer to see the tee not change the 
> semantics of master at all.  With that, I see two issues:
> 
>    - create_similar() creates a tee dup'ing all the surfaces.  It should 
> simply create_similar(master) IMO.  I simply don't see any use in a tee similar,
> 
>    - acquire_source_image() and snapshot() may return one of the slaves 
> depending on type.  I understand why this is being done.  However, it may fail 
> very badly since the slaves and master may have had different initial content. 
>   They are not exchangeable.

The reason why I had to do this was to ensure that a meta-surface could
capture a full DAG of the operations that affected the surface (i.e. I
need to the meta-surface to capture meta-surface snapshots and not just
images from the master surface). This is a vital necessity for the
debugging tools that try to retrospectively determine the failing
operation.
 
> 
> > So those are the insignificant changes off the top of my head
> 
> True.  But 1) involve API, 2) I don't understand the rasterization changes 
> anyway, so I may as well focus on these :P.

Ok -- but I tried to avoid core API/semantic changes, so that we could
easily disable/postpone these issues for 1.10. :-P

> > Given
> > time and motivation I will keep working on the delta-debugger, which
> > will give a clear use case for the XML/tee surfaces. The current wip is
> > util/cairo-sphinx which at the moment will emit traces for every context
> > (captured from a live application) that differ between clients (for
> > which I use LD_PRELOAD to explicitly set the cairo version to use).
> 
> When you're mostly done with this, some documentation about all the different 
> testing, perfing, and debugging tools :).

Truly - it'll be self-documenting as well as self-correcting! ;-)
-ickle