[cairo] Plans for 1.6?

[Vladimir Vukicevic]

On Dec 9, 2007, at 8:17 AM, Owen Taylor wrote:
> On Sun, 2007-12-09 at 00:58 +0000, Baz wrote:
>>
>> 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.)

There is -- CGContextGetClipBoundingBox , so there should be no need  
to maintain both the region and the path.

     - Vlad