How is subpixel-AA implemented in Mustang?

Java 2D
#1

Hi there!

Know thats a bit off-topic bit since the java2d developers look here from time to time its maybe the best way to reach them :wink:

I am currently thinking about howto implement hw-accalerated subpixel-AA with OpenGL and GLSL and would like to know how this is implemented in Mustang. (I plan to contribute the work to Mustang and Glitz - maybe it can be helpful just as prototype)
As far as I can imaging the whole glyph-cache is pretty much unuseable for subpixel-AA glyphs - so is every time a AA-Glyph is rendered to a native surface the background or the glyph fetched from the surface to system-memory, subpixel-aa is done and afterwise a swsurface blit happens?

Since shaders can only access Textures or surfaces bound to textures (FBOs or PBuffers), the only way I can imaging it could be done would be:
1.) Bind the backbuffer to a texture
2.) Create a small FBO for rendering teh glyph to (can be cached if same size or larger)
3.) Render the glyph to small FBO, read composition data from 1.) Texture in glyph cache, 2. background of target bound to texture
4.) Render the small FBO to the target-surface.

I just wonder how slow this would be :wink:
Any better ideas?

Thanks in advance, lg Clemens

#2

couldn’t you just increase the sampling in the pixel format? 4 multisamples gives a pretty good full screen anti aliasing…not sure about sub-pixel tho

DP

#3

We have some code already for “accelerating” LCD-optimized text rendering for the OGL-based pipeline using shaders. This works with our existing hardware glyph caching code nicely (FBO is not necessary). I put accelerating in quotes because this approach is actually quite a bit slower (2-4x at best) than using our software loops. The problem with using shaders in this case is that there can be quite a lot of overhead in enabling the shader and setting up multitexturing just to issue a few tiny texture-mapped quads. The other big issue is that currently our LCD text rendering algorithm needs to read destination pixels in order to apply gamma correction properly, and this is obviously very slow in OpenGL. I’m hoping to find some way we can “fake the math” so we can avoid this readback in most cases.

Anyway, the prototype code won’t make it into Mustang beta, but I hope to work on it a bit more so that we can get something into Mustang. The RFE is:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6274813

If you want to play around some more, you can look at the software LCD text rendering loops in src/share/native/sun/java2d/LoopMacros.h in the Mustang source drops. The non-LCD aware OGL text rendering code is in src/share/native/sun/java2d/opengl/OGLTextRenderer.c. Just be aware (as I’ve said), that the code for doing LCD text in the OGL pipeline is pretty much finished, so you might just want to wait until we put it back in the next few months so that you have some baseline to hack on, rather than reinventing the wheel.

Chris

#4

Wow - can’t believe how innovative the java2d teams became the last couple of years :wink:
Good to know the pitfalls since for sure I would have been fallen exactly into the same (if I were able to produce at least something working) :wink: (still working on my english - is it ok?)
So you’re absolutly right its better to wait until the code is released than to redo work that has already been done.

Thanks for pointing that out - however I am currently also working on a free jvms graphics implementation and because of sun’s strict license I am not allowed to look at the code and work on software thats related to the seen code. I understand this descision however its quite hard since for sure there are parts of the OGL pipeline that would really interrest me ;_)

Thanks for the detailed answer and all the great work done on the OGL-pipeline since Tiger. Can’t believe thOGL backend turned from “not really useful” to “way cool” in just a year.

lg Clemens

#5

I’ve read some WinHec 2004 presentations about Longhorn graphics and they say a few things about text rendering. It appears that fully accelerated subpixel-AA text rendering will only be done on DX10 hardware. Though, it’s not clear what DX10 feature they plan to use in order to accomplish this (and do it fast as well). Avoiding render-target copies is the hardest part, so, access to the destination color from the pixel shader maybe? :o