[cairo] OVER / SOURCE optimization for cairo_paint

[Behdad Esfahbod]

On Tue, 2008-02-19 at 14:14 -0500, Owen Taylor wrote:
> On Sat, 2008-02-16 at 03:29 -0500, Antoine Azar wrote:
> > [ I hope this message doesn't land 3 times on the mailing list. For 
> > some reason the first two attempts didn't go through ]
> > 
> > Hey all,
> > I've got a working optimization that speeds up paint operations for 
> > opaque sources. The optimization replaces an OVER operator by a 
> > SOURCE operator, and in the case of EXTEND_NONE, creates a path 
> > around the source's extents and calls a fill operation instead. The 
> > speedups can be huge, espescially in the case of copying a small 
> > surface onto a much larger one.
> 
> I was hoping someone else would pick up this topic, but since nobody
> else has: is this really a legitimate optimization when the
> source is scaled or transformed?
> 
>  - It will produce clearly incorrect results unless you replace
>    EXTEND_NONE with the (not yet implemented?) EXTEND_PAD, since
>    SOURCE for EXTEND_NONE is going to give 0,0,0,0 pixels outside
>    the edge.
> 
>  - It will produce very different, though in many cases arguably
>    better, results if you do that substitution. Is a 1x1 source
>    scaled up to 20x20 a fuzzy dot or a rectangle?
> 
> In my opinion, optimizations should not change appearance in such
> a way ... even if the appearance is better .... because it means
> that you get discontinuities between the optimized path and when
> you can't optimize for one reason or the other.

Right.  Maybe this should be done for solids only for now?


> The other thing I wonder about the patch in general: what's it going to
> do for a backend where OVER is normal and SOURCE abnormal? Does the
> backend have to reverse the optimization? (In other words, the
> question is: should this optimization be in the image backend
> at a low level or even inside libpixman, rather than in cairo-gstate.c?)

I had this concern but didn't know how to articulate it.  The fact that
it didn't really fit in gstate or surface layer, but I couldn't think of
any other layer that this would fit without having to duplicate in every
backend.  But now I totally agree with you that this probably should
simply go in libpixman.  IIUC the change in fact may have negative
effect on PS/PDF, unless they undo the optimization as you pointed out.

So yeah, by fixing in pixman we've fixed all backends except for quartz.
I guess quartz already optimizes this kind of operations.  So, no loss.


> - Owen

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759