[OpenJDK Rasterizer] Antialiased horizontal or vertical lines.

[Jim Graham]

The behavior you describe is a consequence of the rasterization rules of 
Java2D - coordinates are at the edges of pixels and BasicStroke 
describes an outline that straddles the path with half of the line width 
on either side.  Thus, an integer horizontal or vertical line will be 
half on one row or column of pixels and half on another.

In other words, the rasterization rules require us to split AA lines 
into a double-wide half-opacity rasterization.

The solution for this was to introduce the STROKE_CONTROL hint which 
gives permission to slightly tweak the lines.  When it is set to 
STROKE_PURE then no tweaking is allowed or done and the production JDK 
pipelines will all produce the same result.  But, STROKE_NORMALIZE 
allows us to shift lines by up to half a pixel to avoid the problem.  We 
do this by default.

Note that the implementation does not simply add half a pixel to all 
coordinates - it rounds them to the nearest pixel center in all cases. 
Your solution will only solidify lines that are on integer coordinates.

Also, only strokes are so normalized - fills are left untouched.

So, in short, your solution to simply add half a pixel to the stroke 
coordinates to fix this problem doesn't work with STROKE_PURE and 
doesn't fully solve the STROKE_NORMALIZE case, which attempts to 
increase the solidity of every line regardless of pixel alignment...

			...jim

Denis Lila wrote:
> Pisces doesn't support any of the STROKE_CONTROL hints.
> 
> Denis.
> 
> ----- "Jim Graham" <james.graham at oracle.com> wrote:
> 
>> The Ductus pipeline will do the same thing with STROKE_PURE.  It
>> sounds 
>> like maybe the Pisces pipeline doesn't support STROKE_NORMALIZE yet?
>>
>> 			...jim
>>
>> Denis Lila wrote:
>>> Hello.
>>>
>>> I noticed that anti aliased horizontal and vertical lines are 
>>> not drawn properly. I've described the results (with pictures)
>>> here: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=509
>>>
>>> In the patch, I try shifting line coordinates by half a pixel as 
>>> soon as they're passed into Renderer.java:lineTo, and it seems to
>>> fix it.
>>>
>>> However, this seems a bit too easy, so if anyone can think of any
>>> ways in which this fix breaks something, please let me know.
>>>
>>> Thank you,
>>> Denis.
>>>