Clemens, thanks for your reply.
> Its just my personal opinion, but I would recommend not implementing
> it.
> Xorg falls back to software anyway for anything more complex than
> solid rectangles and blits
> and those code-paths will only be triggered for non-antialised
> rendering with solid colors.
>
> Implementing it in Pisces would help every backend OpenJDK supports
> :)
That makes sense. I think you're right.
> Just checked and I also ignore the STROKE_CONTROL stuff completly in
> the cairo based Jules rasterizer.
> Curious how that could be mapped to Cairo, do you know any more
> in-depth explanation how it works - or examples how it should look
> like?
>
> Thanks, Clemens
Regarding VALUE_STROKE_NORMALIZE the API says:
Stroke normalization control hint value -- geometry should
be normalized to improve uniformity or spacing of lines and
overall aesthetics. Note that different normalization
algorithms may be more successful than others for given
input paths.
I can only think of one example where VALUE_STROKE_NORMALIZE makes a visible
difference between the closed source implementation and OpenJDK:
when drawing anti-aliased horizontal or vertical lines of width 1, Pisces
draws a 2 pixel wide line with half intensity (because integer coordinates
are between pixels). Sun's jdk with VALUE_SROKE_NORMALIZE turned on draws
a 1 pixel line with full intensity. This could to achieved by just
checking for normalization and rounding coordinates to the nearest half
pixel, but this solution seems too simple, and I'm not sure whether I'm missing
anything. It would also probably cause problems when drawing anti-aliased
short lines (which is done when drawing any sort of curve)
Unless, of course, this rounding was restricted to just horizontal and
vertical lines.
Regards,
Denis.
