Sign in to follow this  
Followers 0
ic0de

OpenGL
Rendering a GUI efficiently

5 posts in this topic

I did some profiling the other day and I found that drawing my gui over my 3d scene increased my frametime by up to 30%. I'm using GWEN for my gui but it allows you to write a custom renderer which I did. I used the same terrible techniques as the sample renderer but was able to squeeze out a little more performance by better integrating it into my engine which removed a few OpenGL calls. The problem with the renderer is that the way it works is that I basically get to derive a renderer class and rewrite a DrawTexturedRect function and that is the only way I can get geometry. In the sample implementation (and mine) It places two triangles to form a quad in a buffer on the cpu side when everything is finished drawing or the buffer is full it calls a flush function which uploads the buffer to the gpu and draws it, then the buffer is emptied. The problem is that this happens every frame and I have no way of knowing whether the geometry has actually changed between frames so I have no choice but to do everything all over again. So I was thinking of ways to change this awful setup while only being allowed to use DrawTexturedRect and I thought about instancing a single 1x1 quad (everthing is a quad with the same texcoords) and then scaling and translating it in the vertex shader. But unfortunately instanced rendering is only core in OpenGL 3.1+ and my minimum is GL 2.1 support where it is available as an extension (but probably not on intel cards). So my question boils down to is it faster to draw individual quads (one draw call per quad) that are already in the gpu memory or to use the terrible buffering solution? any other general GUI drawing advice would be appreciated as well. 

0

Share this post


Link to post
Share on other sites

Gwen apparently supports caching (take a look at the ICacheToTexture interface in the base renderer). Unfortunately I haven't tried to implement it yet so I can't say anything about its usefulness.

2

Share this post


Link to post
Share on other sites

Gwen apparently supports caching (take a look at the ICacheToTexture interface in the base renderer). Unfortunately I haven't tried to implement it yet so I can't say anything about its usefulness.

 

Hmm thats very interesting. Depending on how it works that may be ideal. Unfortunately none of the samples seem to use it.

Edited by ic0de
2

Share this post


Link to post
Share on other sites
 

It places two triangles to form a quad in a buffer on the cpu side when everything is finished drawing or the buffer is full it calls a flush function which uploads the buffer to the gpu and draws it, then the buffer is emptied.

 
This waiting (draw other things, then draw GUI) might waste some parallelism.
Do you need normal 3D scene drawing while there is a dialog in front of it? A freeze frame (copy last frame to a texture, then draw it as a full-screen quad) should be cheaper.
0

Share this post


Link to post
Share on other sites

This waiting (draw other things, then draw GUI) might waste some parallelism.

Do you need normal 3D scene drawing while there is a dialog in front of it? A freeze frame (copy last frame to a texture, then draw it as a full-screen quad) should be cheaper.

 

Unfortunately the 3D scene must remain dynamic while gui elements are being displayed.

0

Share this post


Link to post
Share on other sites

I dunno if it's optimal how I have my stuff set up, but I have a simple sprite batching class that I use to draw quads with. I don't really do anything special at all.

 

SpriteBatch manages the state, etc. It's really dead simple and really doesn't do that much work internally. Just tracking a few things, starting a new batch, finally issuing the draw call, etc. I pre-fill the index buffer and cap how large batches can get. Adding a sprite to the batch just needs a Rect for the position and another for the texture coordinates.

 

A batch is a simple struct like this

struct Batch
{
	Vertex2D*	verts;
	Texture*	texture;
	u32		numSprites;
	u32		numVerts;
	u32		numIndicies;
}; 

Then keep a vector of them. Batches hang around until you explicitly purge them, so once you add a bunch of quads, you don't need to re-add them and the only thing that needs to happen is the draw call (and prior memcpy() to push whatever batch verts to the underlying vertex buffer).

 

It's not fancy or super robust, but I don't see why I couldn't draw an entire UI with just one or two draw calls. Drawing thousands of textured quads costs practically nothing, and my framerate is still well into the thousands. What's GWEN doing that's taking so long?

Edited by clashie
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Similar Content

    • By recp
      Hi,
      I'm working on new asset importer (https://github.com/recp/assetkit) based on COLLADA specs, the question is not about COLLADA directly
      also I'm working on a new renderer to render (https://github.com/recp/libgk) imported document.
      In the future I'll spend more time on this renderer of course, currently rendering imported (implemented parts) is enough for me
      assetkit imports COLLADA document (it will support glTF too),
      importing scene, geometries, effects/materials, 2d textures and rendering them seems working
      My actual confusion is about shaders. COLLADA has COMMON profile and GLSL... profiles,
      GLSL profile provides shaders for effects so I don't need to wory about them just compile, link, group them before render

      The problem occours in COMMON profile because I need to write shaders,
      Actually I wrote them for basic matrials and another version for 2d texture
      I would like to create multiple program but I am not sure how to split this this shader into smaller ones,

      Basic material version (only colors):
      https://github.com/recp/libgk/blob/master/src/default/shader/gk_default.frag
      Texture version:
      https://gist.github.com/recp/b0368c74c35d9d6912f524624bfbf5a3
      I used subroutines to bind materials, actually I liked it,
      In scene graph every node can have different program, and it switches between them if parentNode->program != node->program
      (I'll do scene graph optimizations e.g.  view frustum culling, grouping shaders... later)

      I'm going to implement transparency but I'm considering to create separate shaders,
      because default shader is going to be branching hell
      I can't generate shader for every node because I don't know how many node can be exist, there is no limit.
      I don't know how to write a good uber-shader for different cases:

      Here material struct:
      struct Material { ColorOrTexture emission; ColorOrTexture ambient; ColorOrTexture specular; ColorOrTexture reflective; ColorOrTexture transparent; ColorOrTexture diffuse; float shininess; float reflectivEyety; float transparency; float indexOfRefraction; }; ColorOrTexture could be color or 2d texture, if there would be single colorOrTex then I could split into two programs,
      Also I'm going to implement transparency, I am not sure how many program that I needed

      I'm considering to maintain a few default shaders for COMMON profile,
      1-no-texture, 2-one of colorOrTexture contains texture, 3-........

      Any advices in general or about how to optimize/split (if I need) these shaders which I provied as link?
      What do you think the shaders I wrote, I would like to write them without branching if posible,
      I hope I don't need to write 50+ or 100+ shaders, and 100+ default programs

      PS: These default shaders should render any document, they are not specific, they are general purpose...
             I'm compiling and linking default shaders when app launched

      Thanks
    • By CircleOfLight97
      Hi guys,
      I would like to contribute to a game project as a developer (open source possibly). I have some experiences in C/C++ in game development (perso projects). I don't know either unreal or unity but I have some knowledges in opengl, glsl and shading theory as I had some courses at university regarding to that. I have some knowledges in maths and basic in physics. I know a little how to use blender to do modelling, texturing and simple game assets (no characters, no animation no skinning/rigging). I have no game preferences but I like aventure game, dungeon crawler, platformers, randomly generated things. I know these kind of projects involve a lot of time and I'd be really to work on it but if there are no cleary defined specific design goals/stories/gameplay mechanics I would like to not be part of it x) and I would rather prefer a smaller but well defined project to work on that a huge and not 'finishable' one.
      CircleOfLight97
    • By gamesthatcouldbeworse
      Hi, I finally released KILL COMMANDO on gamejolt for free. It is a retro-funsplatter-shooter with C64 style. Give it a try.
    • By phil67rpg

      void TimerFunction(int value) {  glutPostRedisplay();  glutTimerFunc(1000, TimerFunction, 1); } void drawScene() {  glClear(GL_COLOR_BUFFER_BIT);      drawScene_bug();  TimerFunction(1);  eraseScene_bug(); // drawScene_bug_two(); // eraseScene_bug_two(); drawScene_ship(); drawScene_bullet();  glutSwapBuffers(); }