[cairo] introducing a "context backend"

[Chris Wilson]

On Fri, 23 Apr 2010 21:50:35 +1200, "Robert O'Callahan" <robert at ocallahan.org> wrote:
> On Fri, Apr 23, 2010 at 9:39 PM, Chris Wilson <chris at chris-wilson.co.uk>wrote:
> 
> > On Fri, 23 Apr 2010 11:59:12 +1200, "Robert O'Callahan" <
> > robert at ocallahan.org> wrote:
> > > How would people feel about introducing some kind of "context backend"
> > that
> > > lets pretty much all of the functionality of a cairo_t be passed straight
> > > through to a platform context backend?
> >
> > The name I picked for this was cairo_gstate_backend_t, mostly to avoid the
> > confusion that I think arises from cairo_backend_t/cairo_surface_backend_t.
> >
> 
> Does you mean you'd have cairo_save/cairo_restore manage a stack of
> cairo_gstate_backend_t? Because I was thinking they should be backend
> functions instead...

I concur, it's just naming. My only worry here is that the native
operators may save/restore different bits of state than cairo... That just
requires a bit of extra work. (And it's not like we can talk directly to
PS/PDF anyway ;-) And there is also the complexity of avoiding the top
spot in firefox malloc/fragmentation profiles. ;-)
 
> How about 'cairo_context_backend_t'?

That's more in keeping with the historical naming conventions. (I just
have a fondness for gstate. :)

> The goal is to then to pass the information to the backend immediately,
> > and convert the existing implementation into a library of core helpers
> > that the backends may choose to use or to assist them in their task.
> 
> 
> That's one way to do it. With that approach, the existing backends would
> fill their function tables with pointers to the "default implementation".
> 
> Another way to do it would be more like the surface backends; make the
> default be NULL and have cairo_ functions call through to the backend
> function if it's non-NULL, otherwise continue on with the default
> implementation.

The trouble here is that this is often labelled the "mid-layer mistake".

  http://lwn.net/Articles/336262/

And is something I've been thinking about when looking at writing backends
to do scan-line compositing and for DRM. The strategies for converting
paths into geometry and rasterising here is often quite different and at
odds with cairo-surface-fallback.c, which is designed around RENDER.

> Any particular reason to favour one approach over the other? Without having
> thought about it much, the latter approach seems to me slightly easier and
> less likely to regress performance (even a tiny bit) for existing backends.

I think one is just as easy as the other. There is a default
implementation for you to use as a function pointer, or to fallback to.
And being explicit in the backend is preferable, rather than relying on a
higher layer to dtrt.
-ickle

-- 
Chris Wilson, Intel Open Source Technology Centre