[cairo] Clip region problems

[Keith Packard]

On Mon, 2005-05-02 at 16:48 -0400, Owen Taylor wrote:

(a long discussion about clip lists in surfaces)

I've redone the nickle binding (cairo-5c) and the
new restriction that each surface be targetted by only one cairo_t at a
time is causing existing code to break.

I have a multi-threaded application drawing several different objects to
the same surface; each thread wants to have a private graphics state,
but they all want to share the same surface.

Before the BAD_NESTING state, this worked just fine.  Now I get an
assertion failure and my program aborts.

I think we should revisit the discussion which prompted the current
state and see if we really want to keep things like this.

To me, a surface is an object without any state aside from the image
drawn there.  This new BAD_NESTING status breaks that abstraction and
exposes the application to the effect of an implementation detail which
copies clip state from the cairo_t to the cairo_surface_t.  Abstractions
shouldn't be discarded so casually.

Let me try to summarize the current design; errors in this summary will
illuminate my own misunderstandings, which could lead to invalidation of
my ideas below...

Ok, so I believe the BAD_NESTING status was added to allow the cairo_t
to place clipping information directly into the backend for efficient
rectangular pixel-aligned clipping.  A key requirement for efficient
cairo usage in a windowed environment.

The cairo_surface_t clip region is usually just a copy of the gstate
clip region, at which times it would be more efficient to just use the
gstate clip_region directly and not store it in the cairo_surface_t as
well.  The only unusual case is when compositing trapezoids, the
cairo_surface_t clip region is temporarily set to the trapezoid region.

It seems to me what we want is instead of making the surface push/pop
clip lists, we just want the gstate to tell the surface which clip list
is in use for each operation and then have the surface cache updates to
the backend itself.

We just need a way to globally identify region contents and the surface
can tell when the backend must be informed about a new clip list.  In a
similar situation, the X server uses 'serial numbers' -- integers
created by a global counter.  This will be hard in cairo without
locking, but as a cairo_t (and gstate, by associatio) can only be used
with a single surface_t, it seems like we can place a serial number
generator in each surface and use that.

Surely I'm missing something here; this seems like it will be both more
general (allowing parallel cairo_t objects to reference the same
surface) and more efficient (by eliminating duplicate regions in the
cairo_surface_t).

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050517/db790712/attachment.pgp