[SOLVED] Overlay best practises

[Mickelukas]

Hi all,

I'm creating a semi transparent 2D overlay that needs to update quickly (moving windows and so on) and it worked fine until I tried it at FullHD resolution (putting fullscreen in my game for fun). Some comments would be great because I'm all out of ideas.

What I currently do is:

1   2   3   4   5   6   7   8   9   10   11

If an interface component has moved     Clear a buffered image the same size as the window (using fillrect, so slow!)     Draw the interface components onto the buffered image     Tell the OpenGL thread that the overlay has changed The OpenGL thread then picks up the buffered image and makes it into a texture (binding the already existing texture but calling glTexImage2D again) Every loop (no matter if the texture has changed or not)     The OpenGL thread marks parts of the texture to be drawn (where there is a component)     Moves over to a 2D viewpoint     Draws triangles of each marked part using the texture created

The last part (what happens every loop) is really fast no matter the resolution, but the first two parts are really really slow when I'm handling a texture of 2048*2048, which I guess makes sense... it works really great up to 1024*512 though.

What is the best practice around this and how have other people solved it? Handle one BufferedImage/texture per element/window (they are mostly quite small and quite static, the problem is the movement which would be solved then as that's only the triangles moving)? Update the texture using glTexSubImage2D?

Kind regards,
Mike

[lhkbob]

Definitely use glTexSubImage2D.  Smart drivers might be able to reuse the same texture memory when making a new image, but who knows?  Also, glTexSubImage2D can be used to transfer only the parts of the BufferedImage that have changed, if you have an easy way of tracking that.

I would also recommend not updating the texture when the window overlay moves.  If you think of all the components placed with respect to the corner of the overlay, then they aren't moving so you don't need to change how they are drawn.

[Mickelukas]

Definitely use glTexSubImage2D.  Smart drivers might be able to reuse the same texture memory when making a new image, but who knows?  Also, glTexSubImage2D can be used to transfer only the parts of the BufferedImage that have changed, if you have an easy way of tracking that.

I can quite easily figure out what parts changed so that is an option instead of splitting the overlay up into several textures.

I would also recommend not updating the texture when the window overlay moves.  If you think of all the components placed with respect to the corner of the overlay, then they aren't moving so you don't need to change how they are drawn.

Well, I have lots of windows rendered to the overlay and they can be dragged around by the user so I can't make them static with respect to the corner of the overlay.

I'll look into creating several textures instead of one huge one with lots of transparent pixels, update it with glTexSubImage2D and see what happens with the performance

Kind regards,
Mike

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

[Mickelukas]

Creating one texture per overlay element and updating the textures with glTexSubImage2D made a huge difference, no more performance problems for me, thanks!

Mike