<!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> 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. 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). 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 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. I believe we know this coordinate value before running any filtering? 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. Why? 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. 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. 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. Antoine</BODY></HTML>