[OpenJDK 2D-Dev] Rotation per-pixel accuracy

Clemens Eisserer linuxhippy at gmail.com
Thu Jun 5 22:16:28 UTC 2008


The last two days I worked on text-rendering, and although major parts
are missing (caching, optimizations, ...), it works already for no-AA
and grayscale-AA'ed glyphs (I will look at subpixel-rgb later,
frightens me somehow ;) ). I was able to solve the problem with the
corrupted jfloat-arguments, I simply use jdouble now and everything
works fine (could it really be a gcc bug?).

As always I've some questions:

1.) I played a bit with rotated text to see how accurat my
implementation is. I am drawing the text rotated to a BufferedImage as
well as directly to screen and blit the BI to the same position on
My XRender implementation matches almost with the BufferedImage
result, however the existing X11-pipeline differs quite a bit.
The X11-Pipeline is consistent when I draw with AlphaColor or not,
XRender currently is not (because it still falls back to software for
the alphacolor case, I'll have a look at validate later).
When not rotated all results are consistent against each other.
I did some screenshots for some combinations:

Are there rules that rendering has to be per-pixel consistent, with
what should I compare to see wether my implementation works correct?

And how important are cases where advances are non-integer for performance?

2.) When does GlyphList use positions, which common use-case will trigger it?

3.) Does the JDK contain utility functions for native-code.
I would like to write my own glyph-cache-management, and don't want to
flood my implementation with common-use-case code like hashtable or
list implementations.
Does the JDK contain contain stuff like this?

4.) Are there any "good pratice" rules how much memory may be
allocated on the stack within native code?
E.g. XRender expects the rows of glyphs padded to 4bytes, so often I
need to create a small copy with different dimensions.

Thanks for your patience, Clemens

PS:  I blog about this project, if you're interested:

More information about the 2d-dev mailing list