[cairo] 1.10 release schedule

[Behdad Esfahbod]

Thanks Chris for the update.  So, while that's a lot of worthwhile work, I
think it's clear that it needs months of testing before it can be released.
Do you (and others) think master is in good-enough shape to turn into 1.10 in
a matter of two months?

behdad

On 01/12/2010 06:05 AM, Chris Wilson wrote:
> On Mon, 11 Jan 2010 17:32:40 -0500, Behdad Esfahbod <behdad at behdad.org> wrote:
>> Thanks Benjamin for bringing this up.  Can we have words from Carl, Chris, and
>> Joonas?  Chris in particular, what are you doing in your branch?!!!
> 
> The original reason for wip/compositor is that by rewriting cairo-image we
> can speed up glyphs by over 3x along with a moderate boost on other paths
> (the overhead is shifted to pixman, and performance is improved by using
> Søren's experimental flags branch.) Following the same path, it is also
> beneficial if the fallbacks from other backends do not mandate the method
> used by cairo-image (e.g. cairo-xlib forces the use of traps even though
> they are much slower in the majority of cases) so the backends are taught
> to fallback at the highest level. [Basically the current low-level
> compositor in surface fallback is not ideally suited for any backend, and
> we can improve our performance by designing compositors explicitly for a
> particular backend (in particular for -gl, -drm where we can design the
> architecture from the hardware up). The low-level compositor was written
> to interface with RENDER and that limitation has proven to be the
> bottleneck. When the dust settles, we improve RENDER (unless of course
> OpenGL has won by that point).]
> 
> Along the way I plugged in a new -xcb that on a few cairo-traces is 3x
> faster than -xlib [on gm45] (generally it performs similarly, not
> surprising that for the majority of cases we are dominated by text, which
> is stupendously slow on gm45, and those code paths are nearly identical
> between -xcb and -xlib). That comes with a xlib-xcb interface so that we
> can continue to use cairo-xlib on top of cairo-xcb. I also added hardware
> support for drm-i915 and drm-i965 (with a lot of help from Kristian), two
> wonderful backends that are many times faster than -image, an order of
> magnitude faster than -xlib. (This is the reason why the merge is so
> massive, I'm adding 30k+ lines of new code. The changes to the compositor
> interfaces is the reason why it is so invasive and complex.)
> 
> It also contains subsurfaces for restricting drawing to part of the target
> and for using part of the source as the pattern. Subsurface patterns
> require explicit handling by the backends in order to realise them
> properly, again dependent, but not critically, upon the compositor
> shake-up. These have been in demand from gtk+-csw and Mozilla for quite
> some time.
> 
> It also contains the final bit of support required for zero-copy
> snapshots. The current snapshotting code always performs the (single) copy
> upfront, here we add a new internal proxy surface in order to avoid that
> copy unless the unmodified surface is about to disappear.
> 
> In particular, it contains one of the key goals for cairo-1.10,
> cairo_device_t. Exposing the implicit device so that multi-threaded
> applications that modify cairo surfaces in parallel with cairo can serial
> those operations correctly. And ensuring that the backends live up to MT
> guarantees stated in our documentation.
> 
> And the usual assortment of bugfixes that depend on the infrastructure
> changes.
> -ickle
>