[OpenJDK Rasterizer] Antialiased horizontal or vertical lines.
james.graham at oracle.com
Mon Jun 21 12:55:39 PDT 2010
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...
Denis Lila wrote:
> Pisces doesn't support any of the STROKE_CONTROL hints.
> ----- "Jim Graham" <james.graham at oracle.com> wrote:
>> The Ductus pipeline will do the same thing with STROKE_PURE. It
>> like maybe the Pisces pipeline doesn't support STROKE_NORMALIZE yet?
>> Denis Lila wrote:
>>> 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,
More information about the graphics-rasterizer-dev