[cairo] 1.10 release schedule

[Chris Wilson]

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

-- 
Chris Wilson, Intel Open Source Technology Centre