Best way to draw a textfield in OpenGL, when performance really matters?

Question

I'am creating my own GUI library in LWJGL (opengl for Java). I already managed in creating buttons and panels, and I've also got the hover and active states of the components implemented. This question is about finding a fast way to render a complex component. The library should be very performant!

So I pre-render everything I can, before the gameloop starts. I also want to decrease the use of VBO's, triangles, and textures to render a single component. My approach for creating a button is: pre-render the button appearance using a java Graphics object and put the drawing in a Power Of Two sized BufferedImage. That image is the texture.

Then I've got a FilledRectangle class. That class gets a BufferedImage (the texture) and an x, y, width and height. The class creates a VBO that just renders the Button. For the hover state and active state, I really do the exact same thing, except that there is another drawing made with the Graphics object. So I just create another VBO for each state.

When it comes to rendering components that change their appearance, I can't pre-render too much. I want to create a TextField. Now I pre-render the background (the box of the textfield). And I also pre-render the cursor. The text has to be rendered during the game, and I have the following options:

• Rendering the text using a Graphics object from the java graphics.
• Pre-render a spritesheet (a character map) with all characters on it in a specific font, and then use that texture to create a new VBO for every time the text changes. Note that the box of the component and the cursor are seperate VBO's so, when the text changes, I only have to deal with text rendering in a fast way.

My questions

• It's very easy for me to draw things using a java Graphics object, but isn't this too slow when I have to use this during the gameloop?

• Is it OK to recreate a VBO for every visible change?

Answer 1

Is it OK to recreate a VBO for every visible change?

No, this is never OK.

Creating (and destroying) GPU objects at runtime will absolutely kill your performance, and that's on top of the huge amount of state changes you'll need with your current approach. I do understand the appeal of having everything you need to draw nicely encapsulated, but that's not how you're going to run fast.

Drawing text (or other 2D GUI widgets) is a well-understood and long-solved problem; you need to do some research on sprite batching. Some quick Googling turns up this, for example, which may be a useful place to start.