How to lose 300 FPS! [Tweaked and back to normal]

That is probably because elements with no background color don’t get rendered (or with fully transparent background color) as separate objects - container panels.

Anyway, there seems to be lots of similar problems. Maybe we need some NiftyBatchFactory? :slight_smile:

Redid the PTE with images instead. FPS is still near the roof.



Resized the font a bit. Unsure if it’s too big. What do you guys think?



http://www.disenthral.com/files/pte2.png

I’d turn the main font (with the Cr, Fe, etc) down a tiny bit. Other than that it looks good though.



So Nifty is actually much faster drawing an image than it is drawing a plain blank background colour? That sounds like something that @void256 might be interested in knowing as I’d have thought it should be easy to optimise…

1 Like

Yeah… One thing is sure though, it’s a whole lot easier to read. XD



For now it’ll stay that way. It takes a really long time to do these. 118 elements where each line has to be centered manually.



As for being faster drawing images, that’s mostly handled by the engine, but I agree that the combination of backgroundColor + multiple labels in many panels is very expensive to render. I can’t really tell why it’s that way though.

Nifty does not support batching due to lack of Z-order concept, essentially nifty elements drawn first should appear before elements drawn last. This requirement kills batching which requires out-of-order rendering. Right now, each element of the GUI is equivalent to 1 … N draw calls on the GPU.



With proper Z-order, we can batch the render calls. On OpenGL2, we can use a specialized shader for this purpose, making the maximum number of elements on the GUI limited by the number of textures used. So if you use 1 texture, you will have exactly 1 additional object rendered for your nifty gui … no matter how many actual elements are on screen. Performance would improve dramatically.



@void256: Perhaps you can take a look at this? I believe we talked about having undefined render order inside layers, but layers themselves still following the regular first-is-behind concept of ordering.

1 Like

Thanks @Momoko_Fan that explains many things I’ve seen.



Hopefully something can be done about it.