Login  Register

Re: Which JOGL TextRenderer should I use?

Posted by Sven Gothel on Jul 26, 2011; 10:24pm
URL: https://forum.jogamp.org/Which-JOGL-TextRenderer-should-I-use-tp3199861p3201729.html

On Tuesday, July 26, 2011 11:54:43 PM GiGurra [via jogamp] wrote:

>
> Ok.
>
> Under what conditions should the new renderer be faster than the old one ?
> I'm asking cause the old one is actually performing 2x as fast as the new
> one for me, plus the old one also has nice AAed text (even without hw MSAA).
>
> The new TR call:
> tr.drawString3D(backing_gl, dFont, gqt.text, zeroPos, (int) dFontSize, 100);
>
> is taking about 2x (!!!) the time as the old textrenderer calls
>
> curTr.draw3D(gqt.text, gqt.x, gqt.y, 0, gqt.scale);
> curTr.flush();
>
>
> I find this quite interesting :P.


I have taken out the caching of CPU side computation of the curve formula's
coefficients (tex coords).
Hence each frame the whole thing will be computed (cpu/gpu) & rendered
at around ~ 800 fps on my test platform (have to check again).
This means curves are rendered real time at current resolution and transformation.
We can speed this up with mentioned CPU side caching. It's just an API thing here.
Another feature is, this way we have no AWT dependencies (-> mobile).

The old way, you have pre-rendered fonts in a texture,
not resolution/transformation independent.
A performance equivalent would be, if you disable any caching
and process the whole font rendering for each frame.

> Maybe the new TR will be faster with long
> text?
> (To test this I'm rendering the same text sets with both renderers and
> testing with the above lines commented vs uncommented)

Pls drop your demo/test somewhere, so I can incooperate it in a unit test.
Pls add the JogAmp copyright - thank you.
Then we can perform such tests as well.

Both methodologies are not really comparable as described above.
I am sure, we can speed up our stuff a bit (caching, GLSL, ..),
but we will never be as fast as a method, which just dumps a
prerendered texture.
And this is exactly what we try to avoid :)
Otherwise no resolution/transformation independance would be possible.

Cheers, Sven