Ok. So here's the deal. I have a gui heavy game that includes a virtual cockpit with a couple of mfd's with several different pages, a hud, etc, not to mention the normal in game gui and chat boxes. Ok. So I've used BUI and it performed well, but it was pretty limited, especially I thought the mono spaced text looked pretty bad. So I switched to JMEDesktop. It is slick, does everything I want, but it's a performance hog. I still can't quite get out the gc stutters on lower end (P4 2.8 ghz with a 6800 vid card) machine.
So I'm contemplating switching to the flavor of the month, FengGUI. But before I replace my gui for a 3rd time, ugh, I was wondering how good the peformance is and if anyone has seen any stuttering? Also how is the text rendering with it? Also, what level of control over components will I have? I need several gauges and I've done that with both BUI and JMEDesktop, but I just want to make sure there aren't any limitations of using FengGUI that would make that difficult.
Many thanks for any input you might have.
i’m not aware of a monospace font limitation with BUI
screenshot from my project (look at the font on the cards).
Doah! You got me there. I wrote that wrong above. I had used NUI before. So BUI, is it fairly complete with scroll bars and text areas, radio buttons and such?
Further, which is liable to perform better? BUI or FengGUI? I really don’t want to have to replace my UI a 4th time. :’(
BUI is abandonware I believe. :o
FengGUI is your best shot for performance, but there's a lot of UI tweaking you'll have to do on your own.
BUI is not abandoned at all. i update from the trunk at least once a week and i even submitted a patch 
don’t forget BUI is used in Bang! Howdy which was released a few days ago. i noticed there also is a wikipedia entry for the game(which also links on a gamasuta article about bang!).
the reason i use BUI is that it provides only the “standard” widgets, and does not attempt to be a blow-up lib which provide every imaginable widget. usually in a game you have a very specific GUI, which most of the standard components can’t replace. i don’t want to criticize FengGUI in any way. because i took the BUI path and i’m very pleased with it until now i didn’t even attempt to use FengGUI (gui porting is such a pain in the ass). all i did was try out the standard demos and take a look at the classes. i have to say that (at least at the point i dug in FengGUI) they were quite similar in many aspects. both attempt to be as lightweight as possible and that’s the most important thing.
the only “issue” with BUI is that samskivert is quite busy and doesn’t have often time to visit this board. maybe now that the game was released, he’ll have more time.
Slowdive said:
Doah! You got me there. I wrote that wrong above. I had used NUI before. So BUI, is it fairly complete with scroll bars and text areas, radio buttons and such?
i missed this post. ://
yes, with BUI you can do all the text area, scrollbar, buttons stuff. (i personally didn't do anything with radio buttons, but i know there is a BToggleButton somewhere in there). you can create GUI's pretty much like with swing. you have layout managers, containers, and all basic widgets like buttons, combo boxes, text areas, scroll panes, and other stuff i didn't take a look at :)
if you want to see how hard/easy it is to use, grab the source from the trunk and take a look at LayoutTest. it's not meant to be beautiful(you can customize that by yourself with styles - css-like syntax), but only to display most of the components.
about that performance comparison: i remember renanse once posted something about their own proprietary GUI implementation. he mentioned that they used BUI and FengGUI for inspiration. i suppose they did a more detailed comparison. maybe he can tell us more about the results of the comparison.
edit: typos
Hi!
the reason i use BUI is that it provides only the "standard" widgets, and does not attempt to be a blow-up lib which provide every imaginable widget.
:D Hehe, well the reason why we added the current number of widgets was that people requested them. In the beginning (more than a year ago) I wanted FengGUI to be a simle HUD library intended to merely render text and show a few buttons here and there. Then, some guy wrote me a mail if it wouldnt be nice to have text input. So I added text input and all the preliminary stuff that is required (clipping, etc). Couple of days later somebody wrote me if I have an idea how he may build tables in FengGUI. Again, I implemented ScrollContainer and Table. In the JGO we then had a quite heated discussion about a generic GUI library which lead to adding XML support to FengGUI so that you can define your own themes conveniently via XML (which is what we are currently still working on). In the meantime a small number of small-sized companies started to use FengGUI for their HUD and flooded us with bug reports which made me actually regret that I added so many widgets in the first place :) Anyway, we got it pretty stable by now and reached an amount of widgets that covers "the basic needs" from my perspective, including trees, tables, windows (although I dont like my current Window implementation not so much), text fields, menus, combo boxes and so on. You can of course still do the simple things like displaying credit points, scores, and all the things you need for a simple, customized HUD.
We noticed that customizing the appearance of widgets through a description file is often not powerful enough or would require to inflate the parser grammar to a size beyond simple CSS like style. This is why I always wanted FengGUI to be customizable directly in Java, rather than soley relaying on customization via XML. So we strictly separated the appearance from the behavior in all widgets so that both can be replaced without affecting the other too much.
Future plans are to mostly add visually appealing things like a little FX toolbox and maybe adding simple animation support (e.g. displaying a series of sprites). Also we want to further improve text render speed similar to what has recently been added to JOGL for text rendering.
FengGUI is your best shot for performance, but there's a lot of UI tweaking you'll have to do on your own.
Yeah, I suppose that is correct compared to other GUI libraries. The tweaking issue actually comes from the dilemma of customization versus convenience. FengGUI tries to address game developers who tend to have *very* specific ideas about how widgets should look like and how and where and with which size they should be layouted. We thus made FengGUI kind of basic on this behalf to provide more flexibility to the developer.
Regards,
Johannes
don't get me wrong, i didn't meant to criticize FengGUI. i just stated why i had the feeling BUI is better for my needs. for example i'm not sure that BUI is good for anything non-game-like, yet. if i would want to make some editor of some kind (like the rpg toolset, or a modelling tool) i would take FengGUI instead of BUI. as i see BUI was developed with the purpose of having a GUI lib for Bang Howdy. and only the needed things were implemented as the programmers most probably also had other things to do than the GUI 
maybe now that the game is out, samskivert will have more time for BUI. on the other hand, since the release the checkins weren't that frequent anymore.
as a GUI lib user all i want is to have some good options when i need to do some GUI, and i love the fact that there's more than one lib available.
Schabby said:
So we strictly separated the appearance from the behavior in all widgets so that both can be replaced without affecting the other too much.
BUI does that too (or i misunderstood your post)
but i can't wait to see those animation features and the improved rendering (fast text rendering is one of the most important features IMHO)
so keep up the good work ;)
Hi sfera!
Oh I did not feel critized at all. I totally agree with your previous posts including that it is nice to have several GUI libs around. After all we are doing this for fun and not for money. 
I have to confess that I do not know BUI so well, but I will catch up with that soon. For example I am eager to find out how they do decoration-related things like backgrounds, borders and so on. Also I am interested to know how they render text and integrate widgets into jME (I suppose they explicitly use the scene graph).
I just wanted to add my comments on the GUI discussion to this thread. Sorry for sounding to fierce on some points.
Johannes
Schabby said:
I have to confess that I do not know BUI so well, but I will catch up with that soon.
well, then be warned about the coding style of BUI. as much as i like BUI, i'm always afraid to read the code XD
and about the integration, yes, they link between BUI and jme is something (actually a Geometry object) called PolledRootNode which is the root of all GUI and where you attach all your windows.