[cairo] defining CLAMP extend mode

[Vladimir Vukicevic]

A while back (I believe on IRC), we discussed defining a new extend mode 
that would behave a bit more like people expect.  That is, if the sample 
point is within the bounds of the source image, it would be clamped to 
its bounds; if outside, then it would be transparent.  Right now, there 
is a smooth transition between the two areas, which leads to artifacts 
when upscaling.

EXTEND_PAD can help with this, but only if the destination is clipped to 
the actual area of the transformed source image -- that is, calling 
cairo_paint() with no clip and an image source with EXTEND_PAD would 
cause bleed to the left and bottom.  CAIRO_EXTEND_PAD is also not 
implemented for image surfaces in pixman, so this may be moot anyway.

I've looked into implementing this in pixman, and it looks like most of 
the work would be in fbFetchTransformed and/or fbFetch, but that's only 
if one goes through pixman_compositeGeneral.  I didn't get as far as 
figuring out what would be necessary to implement either PAD or CLAMP in 
the optimized paths.

However, there's still a problem.  Even if CLAMP were to be implemented, 
it would still be impossible to take a subrect of an image and scale it 
up, treating the subrect's borders as a hard edge.  This type of 
functionality is used pretty often for storing multiple icons in one 
image, and then rendering just the one that's relevant to the current 
combinations of button state.  As much as I hate to say this, but 
pixman's source clipping would help here, so maybe CLAMP and PAD should 
be defined to treat the source clip bounds as the bounds of the source 
image (which I think is what the current pixman code does anyway).  This 
would require the image surface code to set the right source clip on the 
source surface before calling pixman's composite function.

Any suggestions on how to resolve these problems?  The upscaling issue 
is, IMO, one of the biggest problems with cairo right now; for us with 
Mozilla, we don't have the problem on OSX (since we treat EXTEND_NONE as 
effectively what my proposed CLAMP would be, since Quartz has no way to 
do the smear), but I haven't been able to take advantage of win32's 
stretching functions (because they can only work with integer-aligned 
source and destination rectangles).  And on Linux, this would probably 
require adding Clamp to Render/XAA.

     - Vlad