JOGL TextureRenderer slow?

[Zoomby]

Hi,

I'm still fighting to get some Graphics2D onto my JOGL scene.
I'm using TextureRenderer to create a small 100*100 texture. But then TextureRenderer.getTexture() is damn slow!
If I call it only 10 times in a row, the CPU usage jumps to over 60%.
I used "-Dsun.java2d.opengl=True"

What am I doing wrong? Isn't there a simple and efficient way to draw some 2D graphics?

Bye
Chris

[emzic]

maybe if you can post some of your code, we can look into this.

as for drawing 2D graphics, maybe the Overlay-class which uses the TextureRenderer is more useful.

[Zoomby]

Hi emzic,

Here is my quick test-routine which I call every frame (Imagine I'd like to create animated 2D graphics).
I guess it does the same as the Overlay class (I took a look into the Overlay and TextureRenderer source to see how it works)

As I noted, when I call my "render2D" 10 times in a loop the CPU usage rises to over 60%.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51   52   53   54   55   56   57   58   59

TextureRenderer renderer = null;   int render2D(GL gl, GLDrawable gld)   {     if (renderer == null)     {                 renderer = new TextureRenderer(100,100,true);        renderer.setSmoothing(false);     }             Graphics2D g2 = renderer.createGraphics();     g2.setBackground(new Color(0,0,0,0)); //transparent background    g2.clearRect(0,0,100,100); //clear all         g2.fillRect(0,0,10,10);     g2.setPaint(new Color(99,0,255));     g2.drawRect(0,0,22,22);     g2.dispose();                 renderer.markDirty(0,0,500,500);         Texture tex = renderer.getTexture();     tex.bind();             //draw orthogonal quad.    int x = 45;     int y = 45;     int w = 100;     int h = 100;         y = gld.getHeight()-y;         gl.glBegin(GL.GL_QUADS);             gl.glTexCoord2i(0,1);     gl.glVertex3d(x,y-h,0f);         gl.glTexCoord2i(1,1);     gl.glVertex3d(x+w,y-h,0f);         gl.glTexCoord2i(1,0);     gl.glVertex3d(x+w,y,0f);         gl.glTexCoord2i(0,0);     gl.glVertex3d(x,y,0f);             gl.glEnd();        return 0;   }

Games published by our own members! Check 'em out!

[lhkbob]

Just something that seemed odd to me but why are you marking the TextureRenderer dirty from (0,0) to (500,500) since the width and height of the renderer are 100 each. 

[Zoomby]

Just something that seemed odd to me but why are you marking the TextureRenderer dirty from (0,0) to (500,500) since the width and height of the renderer are 100 each.

That's because it's messy test code.  . But it doesn't solve the actual problem...

[MartinFischbach]

Try not to create Graphics2D with each render cycle, but instead reuse it!

Not:

1   2   3

Graphics2D g2 = renderer.createGraphics(); ... g2.dispose();

But:

1   2   3   4   5   6

Graphics2D g2; // somewhere in field declaration // and within render2D() if (g2 == null) {     g2 = renderer.createGraphics(); }

[Zoomby]

Hi Martin,

sorry, but that doesn't help 
I think renderer.getTexture() is the bottleneck...

[lhkbob]

Could you try profiling it just to make sure?

[Zoomby]

Could you try profiling it just to make sure?

I've never used a java-profiler before...
I can only say:
If I remove the call to getTexture the CPU usage is 7 times smaller.

[emzic]

well getTexture() does update all of the texture that you have markedDirty before. so it does quite a bit of work.

to profile it, just put a System.nanoTime() before and after and measure the difference.

also try making the texturenderer resolution a power of two. 128x128 and not 100x100.
also, never mark something dirty that is outside this resolution since it will result in an openGL error which has a big impact on performance.

Games published by our own members! Check 'em out!

[MartinFischbach]

Hi Zoomby,

I mean, what do you expect?

10 times

creating graphics content
Drawing a 100x100 picture
uploading that picture as texture
displaying texture

PER Frame.

I assume you are running with at least 30fps.