I have noticed that in our game currently when we load the gui's for our inventory that our fps drops substantially. I am using an ATI radeon 5770 GPU and a amd athlon x4 @ 3.5 ghz. to run the game on lowest settings. the frame rates we have achieved are 120-135 FPS without any GUI's open except our hotbar and minimap. But when we open our inventory that drops to a measly 50-71 fps I have no clue what could possibly cause such a massive frame rate issue.
below you will find attached an image of it

http://imgur.com/VoxWs

Are all of your GUI images .png's?

are you overriding the virtual update/draw methods for some elements?
are you rendering the models in item slots as 3d or 2d icons?
try disable some parts of the codes, to not add all gui elements to the inventory, to narrow down the problem

I have noticed big performance drops too when using more than a few gui elements. I could be wrong (don't know EE inner workings), but I think the problem is that every gui element results in a draw call to the video card. So you end up with one or more quads being individually drawn for every element for example. This is the fastest way to kill performance.

If your inventory screen is made up of lots of individual elements, then this is what is happening. You should try and combine as much as possible into a single image to draw at once.

@Esenthel, it would be great if we could get some gui batching happening in EE. A really good example to look at is an Ogre addon called QuickGUI (http://www.ogre3d.org/addonforums/viewforum.php?f=13).

From memory QuickGUI batches drawcalls together using a texture atlas, which it creates on the fly from your individual gui element textures. This results in almost zero performance drop regardless of the number of gui elements on the screen. You always have one draw call whether you have 1 gui element or 100.

(05-01-2012 06:53 AM)fatcoder Wrote:  From memory QuickGUI batches drawcalls together using a texture atlas, which it creates on the fly from your individual gui element textures. This results in almost zero performance drop regardless of the number of gui elements on the screen. You always have one draw call whether you have 1 gui element or 100.

Yes, this is how it should be done.

@Demostenes, fatcoder

Huh, how interesting! Do you guys have any suggestions on how such a thing could be pulled off? I'm not trying to make a dig here, just curious.

If only we could just take the source code for the dratted thing and modify it to fit the engine's code! It'll never happen I'm sure, but a person can dream.

Just to complete it with a GUI Lib not based on using any engine.

NoLimitsDesign with the same features or more I think.

(05-02-2012 03:02 AM)Magnets Wrote:  Do you guys have any suggestions on how such a thing could be pulled off?

Well, EE would need to take the individual gfx files for each gui element, which could either be pre-specified, or ideally added to the collection when first used. These gfx files would then be stitched together into a single larger texture in memory with uv coordinates stored to reference an individual elements location in the texture. This texture would continue to grow up to the maximum texture size for the video card, at which point it starts a second texture. The atlas texture/s could even be written to disk so they don't need to be created again in the future unless an elements individual gfx file changes.

When it comes time to render the gui interface, EE would add the quads for each element to a running vertex/index buffer and set the texture. Then the whole thing is rendered in a single draw call. If more than one texture atlas is in use, then it would result in a draw call for each one. In most situations though, you would only ever have one.