[cairo] Plans for 1.6?

[Owen Taylor]

On Sat, 2007-12-08 at 00:11 +0000, Baz wrote:
> On Dec 7, 2007 11:26 PM, Carl Worth <cworth at cworth.org> wrote:
> > On Fri, 30 Nov 2007 00:57:03 +0000, Baz wrote:
> > > However I guess the one thing I want for christmas is, quartz should
> > > be markked as officially supported.
> >
> > Yes, let's get there.
> >
> > > I knocked together the docs changes etc a while back, the only reason
> > > I've not pushed for it yet is that we fail tests; despite the api
> > > having been solid since March or so. I'm not sure that we'll be 100%
> > > with the unit tests by 2008, but marking quartz as supported isn't
> > > saying that - its just saying that the api is stable, and that we've
> > > got community support; which I hope is there now since mozilla rely on
> > > cairo/quartz on mac. Carl?
> >
> > I have said "should pass the whole test suite" as part of being marked
> > supported, but that's not exactly true of course, (we still have the
> > few XFAIL tests for currently supported backends of course[*]).
> >
> > And it's not even that the automated test suite needs to pass
> > perfectly either. It's currently much too harsh for things like font
> > rasterization details that we really don't care about, for example.
> >
> > The point is that there shouldn't be any "features" that are
> > missing/broken in quartz, (think clipping, masking, gradients,
> > etc.). I want people to be able to write an application with Linux/X
> > and then move it to Mac OS X/quartz and have all the graphics look the
> > same, (to a human---not necessarily to a bit-counting computer). I
> > don't want "oh, yeah, that won't work on cairo-quartz". As long as we
> > have problems like that, we should continue to have the backend marked
> > as experimental.
> >
> > And the fallback approach we have in cairo should make this really
> > simple. That's what let us do "supported" backends for PostScript and
> > PDF even when they had giant page-size rasterization going on. Now,
> > obviously we've done a lot of optimization since then, but we've tried
> > to maintain good fidelity throughout the process.
> >
> > So there is more than just API stability and community support to
> > this. I do want the feature set to be trusted and reliable, (not
> > necessarily bug free of course), from day one.
> >
> > So the obvious question is, what things are still failing in the test
> > suite? Are they things where the test suite is being too picky? Could
> > they be fixed by just doing more fallbacks in the right places? Or is
> > there something else more fundamental that needs to be done?
> 
> 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.

- 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/20071208/125ee1a9/attachment.pgp