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

[Hans-Bernhard B. <br...@ph...>]

Daniel J Sebald wrote:

> course, this demo example doesn't have high enough spatial frequency 
> to cause aliasing.)

That's quite exactly wrong.  All pm3d plots, indeed almost exactly
*every* plot gnuplot is capable of generating, contains ample amounts of
infinitely high spatial frequency details --- every thing we output has
perfectly sharp borders, including the coloured areas generated by pm3d.

> The color bar also looks much better.  (No aliasing possible there in
>  monochrome, unless intentional.)

Aliasing has nothing to do with monochrome vs. colour.  Aliasing
is the artefact invariably created whenever you point-sample (i.e.
render to pixels) a signal at a frequency that's lower than the signal's
actual bandwidth.

For all plot features that have at least one dimension not larger than
one pixel (i.e. dots, lines, and any borders between solid-filled areas,
and vertices of solid-filled polygons), you invariably get aliasing.  It 
manifests itself in the fact that the feature will be displayed up to 
half a pixel away from its "true" position.

>> I think the situation is slightly better for the X11 driver, 
>> because the resolution of the output device is known in advance, 
>> you can therefore round coordinates to get better results.

More to the point: our x11.trm *knows* the (assumed) resolution of the
X11 driver, and it does the reduction to integer coordinates itself.
I.e. the entire rendering process is controlled by gnuplot alone.
post.trm, OTOH, cannot even make an educated guess what the actual
output device resolution --- so it just assumes it's 720 DPI.