[cairo] defining CLAMP extend mode

Bill Spitzak spitzak at d2.com
Mon Oct 23 15:12:58 PDT 2006

I'm quite certain the only working implementation is equivalent to doing 
EXTEND_PAD, after first clipping to a (antialiased) rectangle that is 
the source image boundary transformed to the destination. Don't think of 
it as clamping, the actual sampling *is* EXTEND_PAD and is calculated 
entirely seperately from the clip.

I agree with Vladimir that this behavior is exactly what everybody wants 
and expects, and is what all non-XRender-based graphics api's do. It is 
also easy to replicate EXTEND_PAD behavior by adding one row of pixels 
around the outside edge of the source image.

It is also true that current Cairo can replicate this with EXTEND_PAD 
and push/pop of a clip of the correct rectangle. I would still recommend 
that Cairo be changed to have the above behavior by default, for these 

1. It is exactly what the programmer expects so they won't be frustrated.
2. It removes the need for any sampling other than EXTEND_PAD, thus 
simplifying the code.
3. Other types of image cannot be implemented efficiently or at all on 
some back ends.

Owen Taylor wrote:
> On Sat, 2006-10-21 at 14:27 -0700, Vladimir Vukicevic wrote:
>> 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.
> Your formulation doesn't make it at all easy to get the
> antialiasing right at the boundaries... say I want to rotate an image
> by 45 degrees and draw the upper left quadrant ... if use a fill()
> a rectangle that is the upper left corner, the upper pixels will get
> double-antialiased (yuck!)

Not sure I understand this complaint. Even if you draw two solid colored 
rectangles, the edges will be "double antialiased" and you may see some 
of the first color. This is unavoidable except by going to a 
supersampled destination surface. In fact, doing images as proposed 
above makes such supersampled destinations possible, since it seperates 
the antialiasing from the filtering so you don't lose the filtering.

> And why is the bleed only to the left and bottom? (left and bottom?
> that's a weird combination) I'm probably not understanding the problem
> you are referring to to begin with.

I'm pretty certain the proposal is symmetric. Remember that integers are 
at the *corners* of pixels, not the centers.

More information about the cairo mailing list