Hi :)
In an application I need to draw 2000-20000 strings and I'm looking for hints to preserve ressources in doing this. I was using com.jogamp.opengl.util.awt.TextRenderer ang get some relatively good performances for 2000 strings but "bad" for 5000 (about 15 fps). I followed some topics on the forum relative to com.jogamp.graph.curve.opengl.TextRenderer and after testing it I got about 0.5 fps for 2000 strings. I don't know well the new TextRenderer for now but do you think there is no way to get higher performances using it than using old pre-renderered textures method in awt.TextRenderer ? (as it is said in another topic) Else anyone may have advises for drawing a lot of strings with JOGL ? Strings are all differents and positions may change between two rendering. Thanks in advance for help :) |
Administrator
|
On 04/07/2012 09:16 PM, Djak [via jogamp] wrote:
> > > Hi :) > > In an application I need to draw 2000-20000 strings and I'm looking for > hints to preserve ressources in doing this. > > I was using com.jogamp.opengl.util.awt.TextRenderer ang get some relatively > good performances for 2000 strings but "bad" for 5000 (about 15 fps). > > I followed some topics on the forum relative to > com.jogamp.graph.curve.opengl.TextRenderer and after testing it I got about > 0.5 fps for 2000 strings. The latter changes when creating new strings. Having the tessellated 'curve' data available, rendering is high performance. We really need to look at this, i.e. caching and the GC / memory usage in the current implementation. Probably fixing the latter will already fix the performance problem, which appear on mobile in a very dramatic fashion. > I don't know well the new TextRenderer for now but > do you think there is no way to get higher performances using it than using > old pre-renderered textures method in awt.TextRenderer ? (as it is said in > another topic) pre-rendered .. or cached 'curve' data (graph) would be the key here, yes. > > Else anyone may have advises for drawing a lot of strings with JOGL ? > Strings are all differents and positions may change between two rendering. Yup, we know about such problems and currently graph generates all new curve data for the hw accel. rendering. > > Thanks in advance for help :) Right now we have no fast solution. However, we will look into the graph problems before siggraph. ~Sven signature.asc (910 bytes) Download Attachment |
Administrator
|
In reply to this post by Djak
Things that have speeded up rendering for me in the past (using the old TextRenderer) - Put as much between begin3DRendering/end3DRendering as possible - Don't draw offscreen text (it slows things down even if you can't see it) - Don't draw text that's too small to read (i.e. don't render it until it's big enough to be useful to someone) |
Thank you very much for these answers :)
It explains my test results and also the "freeze" time at the creation of strings (the GC ?) I see the new TextRenderer is a WIP, thanks for this tool. Actually when I asked "do you think there is no way to get higher performances using it than using > old pre-renderered textures method in awt.TextRenderer ?" I meant for now, with tthe current release of JOGL. Thanks for the hints Wade :) Actually, I already consider these points, but I need to check again the point number 1. I willl continue to test different methods. Other hints are welcome :) |
Free forum by Nabble | Edit this page |