I've been working with a few game oriented gui libraries trying to find a good fit. More specifically, a GUI that will work on Windows,Linux,iPhone, and Android with minimal special code.

In my tinkering I've noticed a few libraries like to render the their GUI's to an off screen texture that just display the texture instead.

Is this a common GUI technique?
Isn't there a performance hit with rapidly changing GUIs?

Were I the implementer I would have just rendered the GUI directly each frame. Is there anything particularly wrong or inefficient direct rendering?

Update: By 'game-centric GUI' I mean a GUI framework that doesn't own the window or the main loop. There are other features I'd add but the main loop is the only critical one. This usually involves various rendering backends, input injection, and an update method.

  • \$\begingroup\$ "Game oriented gui libraries" is pretty broad. Can you narrow it down a bit? World of Warcraft has a very different GUI to the original Doom. \$\endgroup\$ Commented Sep 8, 2010 at 5:59

1 Answer 1


Yes, this is a common technique and two immediate benefits spring to mind:

1) The render-to-texture technique as a way to circumvent the inherent issues that come with supporting several resolutions and/or aspect ratios. You can scale the texture to your screen size or just render it in the centre. It's just a way of virtualising your coordinate system.

2) If rendered onto a texture then this can be applied to a mesh or a quad and transformed. For instance, if you wanted your GUI (Menu) to appear at a 30 degree angle to the camera then you'd render to texture, wrap the texture on a quad and then transform the quad.

Most rendering into a texture is essentially the same as rendering into a buffer, so no, there is little-to-no performance hit.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .