<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16608" name=GENERATOR></HEAD>
<BODY><!-- Converted from text/plain format -->
<P><FONT size=2><FONT face=Arial color=#0000ff>Oops I sent my previous mail from 
the wrong address and it landed only in Carl's mailbox instead of the Cairo 
mailing list. Thanks Carl for inlining and replying.</FONT><BR><BR>The problem 
is that that "plus half a pixel extra" is dependent on the filter being used. So 
there has to be some magic to make the treatment of the extend mode actually 
depend on details of the filtering, (which is an entirely separate process later 
in the pipeline).</FONT></P>
<P><FONT size=2><FONT face=Arial color=#0000ff>I might be wrong but I don't 
think it's dependent on the size of the filtering. Suppose you scale an image by 
a very large factor and paint it. When painting the image's right edge for 
instance, the source pixel's coordinates in the original image can never be 
higher than the edge pixel's&nbsp;center + half a pixel. In normalized 
coordinates, this is between [0.0, 1.0]. This is the criteria on which you 
select your sampling behavior.<BR></FONT></FONT><FONT size=2><FONT face=Arial 
color=#0000ff>I believe we know this coordinate value before running any 
filtering?</FONT></FONT></P>
<P><FONT size=2>So not mathematically impossible, no. But it's not "just an 
extend mode" in any sense that we've seen before. And there are lots of 
opportunities for a fix like this to accidentally add a repeated border of extra 
pixels when doing CAIRO_FILTER_NEAREST.</FONT></P>
<P><FONT size=2><FONT face=Arial color=#0000ff>Why?</FONT><BR><BR>Basically, I 
think it's too DWIM of an idea---it violates the boundaries of the pixel 
pipeline, creating delicate interdependencies between them, and making it harder 
to reason about them separately.<BR><BR>And that has implications down into 
pixman, the Render extension, the X server, X server drivers, etc. So I don't 
think it's a good idea. Already, we know that the X server and drivers don't 
have event EXTEND_REPEAT, EXTEND_PAD, and EXTEND_REFLECT working reliably. I 
would not expect EXTEND_PAD_OR_NONE_DEPENDING_ON_FILTER_BOX_SIZE to be much more 
reliable.</FONT></P>
<P><FONT size=2><FONT face=Arial color=#0000ff>Again it shouldn't be dependent 
at all on the filter box size. There might effectively be no support in drivers, 
but I'm pretty sure we can implement it in pixman. </FONT><BR><FONT face=Arial 
color=#0000ff>Antoine</FONT></FONT></P></BODY></HTML>