[cairo] Plans for 1.6?

[Owen Taylor]

On Sun, 2007-12-09 at 00:58 +0000, Baz wrote:
> On Dec 8, 2007 3:44 PM, Owen Taylor <otaylor at redhat.com> wrote:
> >
> > On Sat, 2007-12-08 at 00:11 +0000, Baz wrote:
> > > Actually one of the problems right now is that the /fallbacks/ fail
> > > the tests on quartz. I mentioned this in passing in the mail; the
> > > problem is that the acquire_dest_surface returns an image surface
> > > which refs the buffer used by quartz's CGBitmapContext. So fallbacks
> > > that draw to this bypass clipping (and possibly other things). I tried
> > > to write the fix for this last weekend - which is to make fallback
> > > work the same as eg the windows surface; copy the region of interest,
> > > do the fallback drawing, then paint that back onto the quartz surface.
> > > I didn't get it working yet, I've messed up the coordinate flipping
> > > somewhere.
> >
> > But the windows surface *doesn't* work that way. (Or at least all the
> > time.) If the windows surface is for a DIB (an in-memory bitmap), then
> > acquire_dest_surface() gives you a direct pointer to the bits.
> >
> > The way that clipping is handled is:
> >
> >     /* If we are in-memory, then we set the clip on the image surface
> >      * as well as on the underlying GDI surface.
> >      */
> >     if (surface->image) {
> >         unsigned int serial;
> >
> >         serial = _cairo_surface_allocate_clip_serial (surface->image);
> >         status = _cairo_surface_set_clip_region (surface->image, region,
> > serial);
> >         if (status)
> >             return status;
> >     }
> >
> > If you demand-create the image, then you'd have to save the clip around
> > before you created it.
> 
> I can't use set_clip_region, because the quartz surface uses a clip
> path not a region. I can't recover the clip path from the CGContext,
> but even if I tried storing the clip path in the quartz surface, its
> not useful - calling _cairo_surface_set_clip_path on an image surface
> generates an assertion. Similarly, I can't maintain the clip region on
> an image surface as I go, inside the quartz surface, since I can only
> get the path calls or the region calls, not both (I think). So, AFAIK
> the only answers are to do what I described above, or to switch the
> quartz surface to use the region apis instead - something I haven't
> looked into.

Hmm... that definitely makes it harder. It would definitely be possible
to add a "both" mode to the clipping logic, but the overhead of creating
a clip surface and so forth for cases where fallbacks are *not*
triggered is not attractive.

The algorithm of "make a copy", "composite against the composite", 
"copy back with operarator=SOURCE, applying clip" is not all that
different from the most general path of what cairo does internally - see
_clip_and_composite_combine() in cairo-surface-fallbacks.c.

(Using SOURCE for the copy back is important ... if you use OVER, you'll
get a badly wrong result for destination surfaces with alpha.)

Cairo does optimizations to avoid this most general code-path when
possible ... the one that's most important is the optimization for
the common case of pixel-aligned rectangles. Is there any way of 
querying the clip path/region from quartz? (If you can at least get
the bounding box, that already helps.)

- Owen

-------------- 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.cairographics.org/archives/cairo/attachments/20071209/114fbe93/attachment.pgp