[cairo] defining CLAMP extend mode

[Owen Taylor]

On Mon, 2006-10-23 at 15:12 -0700, Bill Spitzak wrote:
> 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 separately from the clip.

Having the source pattern affect the destination clip certainly would
make an already complex rasterization pipeline worse. Even more so if
(as you imply below) you want to skip it on some platforms.

> 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.

That's a strong statement.

>  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,

The default is still EXTEND_NONE... I'm not sure that's really
changeable within the parameters of compatibility. There are in fact
some cases where NONE is useful - the main one being the case where you
have an image that represents an object on a transparent background that
extends all the way to the source image without clipping.

Maybe Vlad's behavior is close enough to NONE to be substituted without
people knowing ... it certainly is *on average* a more useful behavior;
but the fact that it isn't easily implemented puts a bit of a squash
on that idea. Having a functional PAD would be an easier step forward.

>  for these reasons:
> 
> 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.

The behavior you are asking for is not implementable as sampling if you
are doing antialiasing by any means other than super-sampling.

> 3. Other types of image cannot be implemented efficiently or at all on 
> some back ends.

Well, we know what the *useful* subcase is .. nobody really wants to 
draw with PAD and get leakage beyond the source image, so if that case
ends up as an image fallback, or otherwise, slow, it's not really a
problem.

> 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.

What I'm saying is that if the *source sampling* clips to the bounds of
the source image and uses transparent pixels elsewhere, then you try to
use a destination shape that has the same (transformed geometric) bounds
as the source image, then pixels on the margin of the source image will
have too small alpha values. The source sampled pixel will have a value
of 50%, then you'll cut out 50% again and get an alpha value of 25%
for a pixel that should be half covered.

This will make the edges look ropy and ugly.

Note that this problem will also occur if you implement Vlad's semantics
with clip, since clip and fill in cairo are intersected in raster terms
rather than geometrically.

					- Owen

(All much easier if you use supersampling for antialiasing....)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20061023/bd5a0520/attachment.pgp