Re: [Bug 688243] Spurious lines between joined filled rectangles and antialiasing (fwd)

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:
>> This doesn't seem like a problem that should exist as it is described 
>> below in the manual.  It sounds to me like it has something to do with 
>> the lowpass filter kernel used to rid aliasing.  Perhaps it was 
>> originally written to render in a way that stuck them in a corner 
>> without a lot of rewrite.
> 
> 
> I wonder what's the algorithm for antialiasing is & should be. 
> Currently, it seems that they antialias the current drawn rectangle with 
> its current surrounding (e.g. white background), instead of waiting for 
> some potential future object (rectangle) that will be drawn closely.

Well, of course in the case of nonuniform sampling it is a huge issue.  That's a theoretical issue in the realm of research, if ever it has a solution.  But in the case of a grid of points one would average the colors of surrounding pixels; how many depends on the resolution of the original image versus the resolution of the display.

I'm getting into ghostview more than I care to know, but a rhetorical question would be, Is the 1, 2, 4 something having to do with the number of surrounding pixels or elements that are averaged (i.e., the kernel)?  And if 1 is chosen it means no smoothing?  (I.e., no antialiasing.)  A good routine would figure out how big the kernel should be.

> It 
> would probably need much more memory to antialias the final image (and 
> to remember all graphics elements there).

That is true, but the correct way.  But it shouldn't be too much extra memory in the case of a rectangular grid.  (Perhaps that is why ghostview's image doesn't have this problem.)  Also, I would think there are multirate approaches, e.g., rather than attempting to get the final antialiased image in one pass, use gradual smoothing and several passes to get to the final resolution.

I'll admit that when I did the imaging for the X11 driver I disregarding aliasing (i.e., no averaging is done when the image is decimated).  But I felt that was a case of speed/usefulness versus complete correctness.  If ever the issue comes up, I can address it.  But given the nature of typical image data, it often isn't a problem and it doesn't have a consistent, glaring characteristic like white lines.

Like I said, I'm not seeing this problem anymore.  Don't know why.

Dan