I have some questions about the TextRenderer(s) in JOGL 2.
First of all I see there are two versions: com.jogamp.graph.curve.opengl.TextRenderer; and com.jogamp.opengl.util.awt.TextRenderer; (this is the one I've been using) After starting to use VBOs for my geometry I've just profiled my jogl application and found out that now about 70% of time spent each openGL display call is in the TextRenderer. tr.draw3d(...) tr.flush() (I only make one begin3d/end3d-rendering per iteration so that is not a problem) In order to improve this I've thought of a few ways, but first of all I downloaded the jogl source, and I see that com.jogamp.graph.curve.opengl.TextRenderer; seems to be much shorter code and marked as HW-accellerated, but it seems to take Gl2ES interfaces as input. Is it possible to somehow try this one even when using non-ES jogl profiles? Is there a tutorial or example code somewhere on how to use this HW accellerated variant? I would like to see how it performs compared to the com.jogamp.opengl.util.awt.TextRenderer; Thanks, and sorry if any of my questions are dumb, I am not very good at openGL or JOGL :). |
Administrator
|
On Tuesday, July 26, 2011 11:25:38 AM GiGurra [via jogamp] wrote:
> > I have some questions about the TextRenderer(s) in JOGL 2. > First of all I see there are two versions: > > com.jogamp.graph.curve.opengl.TextRenderer; This is our new thing - disclaimer: API may change a bit. > and > com.jogamp.opengl.util.awt.TextRenderer; (this is the one I've been using) We don't really do anything with this anymore .. (too slow, not res. independent) > > After starting to use VBOs for my geometry I've just profiled my jogl > application and found out that now about 70% of time spent each openGL > display call is in the TextRenderer. > tr.draw3d(...) > tr.flush() > (I only make one begin3d/end3d-rendering per iteration so that is not a > problem) > > In order to improve this I've thought of a few ways, but first of all I > downloaded the jogl source, and I see that > com.jogamp.graph.curve.opengl.TextRenderer; seems to be much shorter code > and marked as HW-accellerated, also marked as resolution independent. > but it seems to take Gl2ES interfaces as > input. Is it possible to somehow try this one even when using non-ES jogl > profiles? GL2 interface extends GL2ES2, so does GLES2, GL3, GL3bc, GL4, GL4bc. Hence .. you can pass anything but GLES1. > > Is there a tutorial or example code somewhere on how to use this HW > accellerated variant? I would like to see how it performs compared to the > com.jogamp.opengl.util.awt.TextRenderer; OFC .. http://www.youtube.com/user/sgothel?blend=4&ob=5#p/u/0/Rqsu46ifMaw http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/graph/demos/GPUTextNewtDemo01.java;h=b9a04549816e9707e04a8b592fe77bdfefa9069d;hb=HEAD .. same thing. Further reading/intro to new curve rendering (incl. text): http://jausoft.com/blog/2011/04/01/resolution-independent-gpu-accelerated-curve-font-rendering/ http://jausoft.com/blog/2011/04/01/res-gpu-curve-font-screencast/ http://ramisantina.com/blog/?p=73 http://ramisantina.com/blog/?p=98 > > Thanks, > and sorry if any of my questions are dumb, I am not very good at openGL or > JOGL :). such questions can't be dumb Cheers, Sven |
This post was updated on .
Thanks a lot! :).
Do you also have some code example with it? Like helloworld-ish? :) I checked your links but my eyes could not spot anything, and one of the links seems to be down (http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/graph/demos/GPUTextNewtDemo01.java;h=b9a04549816e9707e04a8b592fe77bdfefa9069d;hb=HEAD) Like, I have no idea what I'm doing here and I've never worked with shaders type of thing ^^- I tested with the following during my gl listeners init callback: final ShaderState shaderState = ShaderState.getShaderState(backing_gl); // backing_gl is my GL2 interface System.out.println(shaderState); final Factory factory = new Factory(); System.out.println(factory); final RenderState renderState = RenderState.createRenderState(shaderState, factory); System.out.println(renderState); final com.jogamp.graph.curve.opengl.TextRenderer tr = com.jogamp.graph.curve.opengl.TextRenderer.create(renderState, 0); but the shaderstate I get is null :P. I'm guessing this is the completely wrong way to do it ^^ |
Administrator
|
On Tuesday, July 26, 2011 04:09:54 PM GiGurra [via jogamp] wrote:
> > Thanks a lot! :). > > Do you also have some code example with it? Like helloworld-ish? :) > > I checked your links but my eyes could not spot anything, and one of the > links seems to be down > (http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/graph/demos/GPUTextNewtDemo01.java;h=b9a04549816e9707e04a8b592fe77bdfefa9069d;hb=HEAD) hmm .. up again, seems we have apache srv difficulties :( here is the actual GLEventListener http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/graph/demos/GPUTextRendererListenerBase01.java;h=0fced47158760ff3777a4f1dc16fcf42928786b8;hb=HEAD |
Yeah but my problem is I dont understand how to get the shaderstate or renderstate objects which are required to create a textrenderer object
EDIT: Hooray the first link works! :) I see now! thanks EDIT2: It works.... This will be awesome ^^ |
In reply to this post by Sven Gothel
Question that I couldn't find an answer to:
The call tr.drawString3D(backing_gl, dFont, "TEST", null, (int) defaultFontSize, 400); The last parameter is supposed to be some FBO size... The FBO size of what, each cached string ? In bytes? or pixels? or some resolution? I changed this number from 400 to 1 and the rendering was the same, so I'm wondering what the number does and what I should put it at :P. |
Administrator
|
On Tuesday, July 26, 2011 06:44:21 PM GiGurra [via jogamp] wrote:
> > Question that I couldn't find an answer to: > > The call > tr.drawString3D(backing_gl, dFont, "TEST", null, (int) defaultFontSize, > 400); if you use 1 pass renderen (demo Base01, as referenced) the size is ignored. for 2-pass it's the 1st pass fbo size, it's semantic is a bit like the higher the better. but thats not quite correct as I understand Rami. He will change this for auto settings .. later on. I would stick to 1-pass for now, Base01. ~Sven |
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 which my laptop's crappy intel gpu cannot do :P). 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. 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) Perhaps the new TR would be faster than the old TR on a better GPU? (I am out "in the forest ^^" during summer with my laptop). |
Administrator
|
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 |
Ok that explains it all. Thanks. My current test is quite heavily integrated into my own project but I'm going to write my own text renderer soon and ill try to compare all 3 in there. However I don't expect mine to be anywhere near as versatile as yours as it will be specialized for my purposes
|
In reply to this post by GiGurra
Did you ever get this working?
I tried to use your text rendering code here, but I get an error that says the text renderer is not initialized. When I initialize it with .init, I don't get any compile errors, but I get the following runtime error and nothing is rendered: createAndCompileShader: Pre GL Error: 0x502 Help??? Thanks so much. |
Free forum by Nabble | Edit this page |