Re: Release critical or not? [was Re: strange box-offset]

[<tim...@en...>]

Hans-Bernhard Br=F6ker wrote:
> Ethan A Merritt wrote:
>
>  =20
>> The length in pixels of a line that starts at pixel x1 and ends at pix=
el x2
>> is (x2-x1)+1.   So this code looks correct to me.  It may well be that=
 some
>> terminals interpret w and h incorrectly, but that would be an error in=
 the
>> individual terminal driver, not the core code.=20
>>    =20
>
> It can't really be an error --- for the simple, if somewhat shameful=20
> reason that the terminal API fails to actually specify what the 'width'=
=20
> paramter of the fillbox call is supposed to mean.  In other words, we'r=
e=20
> staring directly into the face of a serious design flaw.  That'll need=20
> to be ironed out.  The only open question is: is it urgent enough to=20
> warrant delaying the release?  I don't think so, based on the ratio of
> exposure versus complaints about this feature.
>  =20
I agree that it's not worth a delay.
>  =20
>> IMHO an off-by-one-pixel error is not release-critical, however.
>>    =20
>
> On the GUI terminals, it rather probably isn't --- they all effectively=
=20
> oversample, so the error is actually smaller than one pixel.  The=20
> critical ones are the pure pixel formats (which don't oversample), and=20
> the vector-based ones (because they may get zoomed up uncontrollably,=20
> later).
>  =20
As far as I can tell, the X11 and Windows terminal are "pure pixel=20
formats". I think the offsets are not visible in the X11 terminal=20
because the default line style "-3" is two-pixel-thick. For sure, the=20
aqua and wxWidgets terminals oversample.
> Which reminds me: in a certain light, this is a re-play of that bug=20
> concerning microscopic gaps in pm3d maps and colourboxes caused by=20
> aliasing artefacts, in our PostScript output rendered by Ghostscript.
>  =20
That's another problem. Antialiasing is rocket science, and when it=20
comes to adjacent polygons, most coverage-based algorithms will give=20
visible seams (look at the pm3d output for the aqua terminal as an=20
example : http://aquaterm.sourceforge.net/aqt/img/gnuplot1.png). Those=20
algorithms need additional information to perform well in this=20
particular case. Others which are more brute force, like=20
full-scene-anti-aliasing, may give a satisfying result at the price of=20
being more computation intensive.

> This can become a first TODO list item for post-4.2.
>  =20
Ok. Post-4.2 will be exciting !

Best regards,

Timoth=E9e