[cairo] Quartz stroking

[Vladimir Vukicevic]

On 8/18/09 10:46 AM, Andrea Canciani wrote:
> On Tue, Aug 18, 2009 at 7:07 PM, Vladimir Vukicevic<vladimir at pobox.com>  wrote:
>> ...
>> Odd; can you attach the actual images?  It sounds like something is wrong
>> with the stroke width/matrix, not with using ReplacePathWithStrokedPath.
> Here is the output I get running the test on image and quartz.
> I'm running on 10.5, but I expect the same result to appear in
> previous versions.
> Can you please check whether you get the same output?

Interesting; I would not be at all surprised if there were bugs in 
Quartz's unantialiased output.  There were some in the past, and it's 
not a frequently used operation in Quartz so I suspect it doesn't really 
get much testing.

>>> I think that the quartz backend should be fixed by always using
>>> CGStrokePath (using an appropriate CGPattern) and I will prepare a
>>> patch to do this (or another fix, if somebody suggests a better
>>> solution) unless the current behaviour is expected (in this case it
>>> should probably be documented somewhere).
>>
>> CGPatterns are quite slow, and require extra memory tracking work; they
>> should really be avoided if possible.
> Are they slow just because in cairo they are created converting a
> cairo surface to a CGImage and then drawing it or would they be slow
> in any case (even if they were just wrappers for shadings, for
> example)?

Well, for the cases where they're currently used in the surface, a 
CGImage has to show up at some point anyway, so I don't think there's 
any extra slowdown related to using a CGImage (though, I guess, there 
would be if a non-Quartz/QuartzImage surface was used as a source). 
Using a CGPattern is just extra work that it would be better to avoid if 
we can.

Just please make sure you run the perf test suite as you make any of 
these changes, as a number of fast paths got added here specifically to 
accelerate common operations (heavily slanted towards Firefox 
performance) -- e.g. avoiding using a CGPattern and instead using 
CGContextDrawImage if possible resulted in a significant speedup.

     - Vlad