[cairo] Cool stuff

[Behdad Esfahbod]

Thanks Chris,

Comments inline.  Far far from exhaustive.  Just can't go over it all in a day 
or a week!


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.


>   * 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:

cairo_public cairo_surface_t *
cairo_tee_surface_create (cairo_surface_t *master);

Looks good.


cairo_public void
cairo_tee_surface_append (cairo_surface_t *surface,
                           cairo_surface_t *target);

_append somehow suggests an ordering.  I'd prefer _add and _remove.  _remove() 
is useful: you may want to start/stop XML logging.


cairo_public cairo_surface_t *
cairo_tee_surface_index (cairo_surface_t *abstract_surface,
                          int index);

s/abstract_surface/tee_surface/ or s/abstract_surface/surface/?

Again, _index is not my favorite.  But works.  I assume 0 will be master always?


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 XML surface. Again another very simple surface that was added
>     solely to record the sequence of operations that constituted this
>     surface. The distinguishing factor is that its output is both very
>     simple and explicit (e.g. no resource references for patterns, a
>     surface pattern is either represented as an image or by its complete
>     sequence of operations). My purpose behind adding such a 'useless'
>     output is so that I could simply capture the complete state and feed
>     it into a hierarchical delta-debugger to perform state bisection.
>     (The XML format is then convenient since there is large body of DOM
>     parsers - though the style of output is very simple to convert into a
>     CairoScript trace using a simple/fast SAX parser.)

Interesting.  I'll give it a try later.


> 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.


> 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 :).


> On to the good stuff!

No comment on those right now.  My only feeling is that the number of 
different representations, compositors, and fastpaths is approaching ∞.

Cheers,
behdad