Hey monkeys, I made drastic changes in the way jME renders Nifty’s things.
You should notice around 10% speed improvement on desktop (with a full screen nifty layout) and around 400% on android.
That’s not a typo, 400%!
This makes nifty really usable on android devices. Slow nifty on android was not Nifty’s fault, it was jME’s.
The thing is we were updating the color buffer of each quad on each render and there was a branching in the Frag shader of the material. those two things are fps killers on android (not that much on desktop, but still).
Also now fully transparent (alpha = 0) quads are not rendered anymore, this allow to use more complex layouts (a transparent layer in a transparent layer in a transparent layer…and so on…) with no rendering cost.
I tested it with the jME’s test (Nifty Examples and Hello Nifty) and with home made menus and everything works. But i’d appreciate any feedback on this, specially if someone has an issue.
Wow, nice work!
Like it! 
Very nice 
I need to get my android deployment working again. I created a new project and now when I select android device as the target and hit debug it builds but then runs the normal version of the app instead of pushing the apk out to the connected device. 
thx @nehon anything to improve the android functionality is very much welcomed :D!!
@zarch make sure usb debugging is selected, and that you do not select use sd card.
@zarch said:
I need to get my android deployment working again. I created a new project and now when I select android device as the target and hit debug it builds but then runs the normal version of the app instead of pushing the apk out to the connected device. :(
make sure "Compile on Save" is disabled, as said in the manual and in the note on the android deployment settings page..
That’s great new @nehon but my question is about Nifty’s performance when updating several labels on the screen. Will this still incur the GC to go crazy every 5-10 secs?
As it is I removed all that info because of the above. Constant hitching is pretty bad.
Thanks for fixing that anyway.
Right now we create a new BitmapText each time a text is changed into Nifty. So really that’ snot Nifty’s performance, that’s more jME’s way of rendering it.
I’ll look into it, but i can’t guarantee there is a way around this.
Hopefully you can find a way to do that.
If not then I’ll remove the infos that get updated the most.
There is overhead in the nifty layer anyway if all you plan to do is display some rapidly changing information. It might be better to just use your own set of BitmapText for that… and even then, BitmapText will recreate its mesh (or at least the buffers) when the text is changed. Still, at 60 FPS I’d expect you to be able to go longer than 5-10 seconds between full GC.
The info that is causing the hitching is mostly debug so it’s not a big deal. Right now I went the drastic way and completely removed the panel. Hitching was around 10 secs.
The panel content will be completely revised and redone at some point with game-relevant info only. It’s not necessary to have the player’s coordinates constantly updated to be honest.
As for FPS, it’s hard-capped at 500 FPS.
@madjack said:
As for FPS, it's hard-capped at 500 FPS.
Well, then in theory, with a more realistic update speed you could lengthen your hitch time by almost 10x by just updating it at 60 FPS (your monitor is likely not showing better than that anyway). If it's not time critical information you could even do it at a much lower frequency.
This may be half-old post and I hate to bump it but I just want to show my appriciation. It is probebly this that made my game run much better with the newer versions
Thanks nehon!