Why doesn't Unity's GUI work for you?

• What's wrong with Unity 3D's UI?
• How will the new GUI fix those problems?
• Why not use 3rd party UI?
• Do 3rd party UIs have their own problems, or is being 3rd party a problem?

There's a fair amount of harping on Unity's UI, to the point of necessitating the "Is the new GUI out yet dot com" announcement. But I can't seem to find many rationals.

I've tried Unity's UI, looked at 3rd party packages, and I don't find them to be particularly pleasant to work with myself. What doesn't work for you? Why?

Or is it a case of "why can't the GUI just make itself already?"

EDIT: confessional time - I'm making a UI middle-ware for Unity: uiink.com

 

#1
it lacks features, doesn't have that good performance and is not that comfortable to use
#2
It will address all of the issues (hopefully)
#3
Because people don't want to pay extra

 

It's lacking loads of features, it's slow, it eats up draw calls like nobody's business, it's ridiculously awkward to use, and I DO use a third party tool but I shouldn't have to when we've been promised a new GUI system since the 3.X cycle began. At this point we have to use third party solutions to get around the deficiencies in Unity's "features" at almost every step.

 

It's extremely slow, it results in horrible code and code flow, isn't extensible, it lacks many features that you'd expect, it's oververbose for the task at hand... then we get onto the niceties that you want with a modern system such as some form of WYSIWYG editor, the ability to save/load in layouts in a markup of some sort and so on.

It's just a very intensive way to do something that from the perspective of a user/scripting it should be a lot simpler and quicker. Look at stuff like Qt, Flash, even HTML and compare that to the GUI development process in Unity, everything is far too explicit there's no sense of templating or convenience use of callbacks, the code itself can't reflect the nature of the layout either, in most GUI systems you can completely separate function code from layout code and make use of anonymous coding, doing so makes it so much less painful to do layout, have a workflow between artists and developers when creating layouts, reuse function code, build dynamic layouts, create editors, write clean clear code that visually reflects heirarchies and grouping within your layout in a more succinct way, create import/export functions to dynamically create layouts from e.g. xml files edited elsewhere by your design team.

There's a lot that can be done to improve the design strategy of the GUI within Unity.

Third party solutions aren't much of a solution either, not that they can't be good, but you're making yourself dependent on a third party with whom you only have a tenuous contract, they may simply stop developing their product, maintenance and support in general can be flaky and is an unknown quantity. Not through any fault of those developing or selling those products, but just the fact that if it's some guy on his own working away in a room somewhere life can happen to that guy, family problems, health problems, anything, and then as a customer you're kinda stuck which may be a problem if you're mid project. If UT develop an in house solution then you're going to feel that little bit more secure about using it, and that it'll be around for some time to come.

 

The two things that kill it for me is that it overloads drawcalls, and none of the widgets are set up to be used with touch input very well.

If it had lower drawcalls and it felt like actual native iOS UI, I would be good with everything about it.

 

The newer mobile devices arent really draw call limited anymore.

 

I find it quite hard to make anything complex or dynamic. I don't find it as bad as some people are making it out to be, but I don't feel as if it should take over 1000 lines of code to make an upgrade/store menu.

 

I don't use it because the limitations in the framework of the thing are dramatic. Coming from a modern programming background, Unity's GUI is a train wreck. Let's start with the obvious reasons why: it's buggy, slow, eats memory like a poor, overweight New Yorker eats McDonalds, is not extensible, and hasn't gone anywhere or undergone any major revisions.

But there are other reasons as well. First of all, it produces lengthy code (a modern setup will be 1k lines or longer) and it encourages bad programming practice by mixing GUI drawing code with event handling code, which you should never do. Which brings me to my next point - no callback support, which means clutter like nobody's business.

At this point, virtually everyone is using a third-party tool to cover Unity's definicies. So jump on board - forget about using Unity GUI at all and use NGUI or similar - you're in good company.

 

1) Performs too slowly, no visual editor
2) I can only hope
3) What I'm doing currently
4) Rare for the fast 3rd party GUI's to have simple textbox operations like selecting areas of text or copy+paste

 

So what exactly is 'wrong' with the 3rd party packages? Have you used NGUI? What is wrong with it that you don't like it?

 

Because it isn't the 3.5 GUI.

 

....where do you draw the line? A lot of phones out there still have 512mb of ram. I use a couple devices with 512mb to test with as that's my baseline. In the past, going up to 100+ draw calls would crash depending on what they were and whether code/physics was affecting objects.

 

That doesn't change its overall slow performance and it doesn't excuse inefficiency at all.

 

First, I'm going to be a detractor. So far, I like the Unity GUI system, I haven't had any problems with it, and I'm honestly not sure what all the fuss is about.

While the Unity GUI set provides basic controls only, I wrote myself a few wrappers that vastly improve the usability of those assets, with abilities including tweening location and color, and built-in tooltip support for hoverable elements (PC/Mac Only, obviously). I have further improvements planned to simplify the usage of this enhanced Unity GUI further with audio and possibly built-in execution of a remote function via the delegate types introduced in .NET 3.0.

The 'new' GUI may or may not remove the need for me to do this work, but I hardly feel it wasted. The only obligation Unity Tech has is to bring us the tools to do the job with, not the 'would be nice' features that we're all more than intelligent enough to implement ourselves, or sell on the Asset store for those who have pursued other paths (which, makes you smarter than me, because Arts are hard!) Even then, I may attempt another project which takes my GUI assumptions and totally blows them out of the water, which means I will have to be extra-smart with whatever non-standard GUI setup I will need to implement in that exceptional project.

3rd Party Tools may or may not expand on Unity GUI, or go a totally different capability. If I need that totally different capability, there is no doubt the 3rd party tool is correct for the job; if I just need a basic way to present a player with information that is stylish and customizable, there is no reason the default Unity GUI isn't sufficient for the job. This can be mitigated, however, if the 3rd Party tool is either easier or more difficult to work with; a worse workflow will push me back towards doing what I can with the Default GUI, while a more permissive tool will push me towards that other tool if the situation requires it. Not all situations are created equal. So far for my needs, the Default GUI is more than sufficient for what I need.

For the final question, being third party is not a problem; ease of implementation, flexibility, and suitability to the problem at hand are what make me consider or reject a tool. A game is a software package, among other things, and I need every edge I can get with building it quickly and correctly, and being able to understand what I've done six months after the project is done and I have to go look at it again for some reason.

EDIT: Reading the thread, I see a lot of what the OP is trying to cut through - lots of snarling about the Default GUI, but no substance to the responses on why Unity's Default GUI sucks as much as one would be persuaded to see from all the responses. Even the argument about iDevices with 512MB of RAM is at best a half-argument, because no one appears to have even tried to obtain benchmark data between Unity Default GUI, NGUI, and any other popular options out there for this worst-case configuration, let alone more standard ones. I'd like to see this data myself; if the honestly-procured data is good enough, you could even convince me to change my stance. Being an engineer, I do love to see efficiency...

 

^^ you don't develop for mobiles do you?

 

Show me the metrics, pretty please. Obviously if mobile is your target, show me your benchmarks against mobile; if your assertions are true, it will undoubtedly appear in the data you reveal.

Unity Pro has a profiler that comes with it for those of you rich folk, and for everyone else, fortunately a good benchmark is not too difficult to accomplish [C#]

Note: the given link involves an external framework and runs in Visual Studio; something similar could easily be cooked up in Unity, and data written to a file using simple System IO commands.

Note II: While in my post I disagree with the anti-Default-GUI position, I do not necessarily deny that it has performance problems, either. I want to see metrics backing your position up. All I ask is that you back your arguments with data. I have already said my opinion, whether accurate or otherwise, and since that is out of the way, I am open to civilized discourse backed by evidence as to whether my ideas are valid or not.

 

I do a bit of editor scripting work (for example my Editor Charts package in the asset store) and quite like working with Unity GUI.

My original motivation for moving away from it was draw calls, I don't know about hard data, but I do know a few (mobile) generations ago I had some pretty major performance issues due to draw calls. I expect thats not so much an issue now, but I also expect if you have complex graphics or a complex UI that the draw calls will still be an issue.

Another issue is the time it takes to set up GUI, for example heres a UI (free on the asset store) that I built for NGUI and Unity GUI: http://jnamobile.com/samples/ColorableFantasyUI.html. I got the NGUI demo done in about 30 minutes. The Unity GUI skin took about 90 minutes (excluding the colouring code). Note that I didn't try to make them exactly the same erring on the side of whatever was easier to set up in the given framework.

Layout and advanced controls in Unity GUI are still hard. I've written multiple GUIs and editors but I still run in to issues. Some simple obvious layout or control will sometimes cost hours of research and experimentation instead of minutes. Obviously frameworks will help with this (in house or from the asset store), but its still something I run in to too often.

I'm hoping the new GUI will be similar to the old one; a few key improvements and it could be quite good

PS Excuse the asset store advertising

 

I didn't say there was anything "wrong" with them per say. What I'm mostly interested in is what works for people and what is preventing solutions from working for people. Singling out NGUI; I understand it solves many of the issues people have with the built-in GUI - and I'm interested in what those are. I haven't tried using it, only having watched the official video tutorials. From my point of view personally, coming from working with GUI's provided by platforms (Android, iOS, Qt, GTK etc), it doesn't mesh well with how I'm used to building UIs.

I don't want to bash on 3rd party GUIs or even the current built-in GUI - what I do want is to find out what works, what doesn't and what people want. Each GUI system for Unity brings something to the table, I would like to be able to sort out what the pieces are (both good and bad).

 

@JohnnyA Have you tried bench-marking the two versions of your UI on mobile? You said they weren't exactly the same, but the results could still be interesting. @Asvarduil makes a good point regarding actual testing of performance.

What about draw calls? Did NGUI help with reducing the count?

 

There's little doubt that Unity GUI is draw call hungry. Create a UI with a bunch of components and you will get a bunch of draw calls.

This is an only an issue if draw calls are a limiting factor on your performance. In the past on mobile this was very common. Its less so these days but still could be an issue.

CPU usage for Unity GUI tends to be a high because you run through your code each frame. To some extent you can code around this, but it requires more through/effort. Performance on the scene I mentioned earlier for NGUI is approximately*:

NGUI - CPU: 0.5ms per frame GPU: 1.5ms (Draw calls 10**)
Unity - CPU: 1.5 ms per frame GPU: 1.5ms (Draw calls 22**)

I did notice both had a few spikes at start up NGUIs were longer although not larger. Note that both these GUIs do nothing if not interacted with.

Interestingly I did a strategy game where the entire game was rendered with NGUI. Because there were a massive number of widgets (10k+) I had to make some updates to NGUI to stop it recalculating things it didn't need to. Applying this to even the simple scene reduces CPU by about half (in the case of the game it was the difference between 10fps and 60fps... NGUI does an awful lot of calculation it doesn't need to).

* Don't consider this hard data, if you want to check it out yourself just set up a GUI with 20 or so elements in Unity GUI and NGUI.

** Draw calls wouldn't be affecting performance here. Note NGUI draw calls could be further reduced by using less panels.

EDIT: @Cake - Funny you asked I just did that.

 

Further to that just did some test while interacting with the UI. Unity GUI had much higher spikes when clicking things*:

Unity GUI:


NGUI:


* Note I didn't click the colour change button which has to create new texture for Unity GUI and was accordingly take MUCH longer.

 

A great start! Thank you for this data. May I ask in this impromptu test how many GUI elements were under test?

EDIT: I saw your in-progress benchmarks, those are some interesting stats, especially on click. What GUI elements were under test? I would love to attempt to recreate your results.

 

Code (csharp):

1.  
2.     /// <summary>
3.     /// Unity GUI hook.
4.     /// </summary>
5.     void OnGUI() {
6.         if (!hasUpdatedGui) {
7.             ColoredGUISkinMobile.Instance.UpdateGuiColors(primaryColors[0], secondaryColors[0]);
8.             hasUpdatedGui = true;
9.         }
10.         GUI.skin = ColoredGUISkinMobile.Skin;
11.  
12.         // Window
13.         dragWindowRect = GUI.Window (0, dragWindowRect, DoDragWindow, "Drag Window");
14.  
15.         // Alt Window
16.         GUI.Window (1, new Rect(600,100,300,200), DoWindow, "Static Window");
17.  
18.         // Level Window 1
19.         GUI.Window (2, new Rect(350,400,200,208), DoLevelWindow, "1      A Level", ColoredGUISkinMobile.Skin.customStyles[0]);
20.        
21.         // Level Window 2
22.         GUI.Window (3, new Rect(500,400,200,208), DoLevelWindow, "2      A Level", ColoredGUISkinMobile.Skin.customStyles[0]);
23.        
24.         // Lock Window
25.         GUI.Window (4, new Rect(650,400,200,208), DoLevelWindow, "", ColoredGUISkinMobile.Skin.customStyles[1]);
26.        
27.         // Switch Scene Button
28.         if (GUI.Button (new Rect (760,30,120,48), "To NGUI")) {
29.             Application.LoadLevel(0);  
30.         }
31.        
32.     }
33.    
34.     void DoDragWindow (int windowID) {
35.         GUILayout.BeginVertical();
36.         GUILayout.FlexibleSpace();
37.        
38.         GUILayout.BeginHorizontal();
39.         GUILayout.FlexibleSpace();
40.         // Button
41.         if (GUILayout.Button("Button")) {
42.             // Button function
43.         }
44.         GUILayout.FlexibleSpace();
45.         GUILayout.EndHorizontal();
46.        
47.         GUILayout.BeginHorizontal();
48.         GUILayout.FlexibleSpace();
49.         // Button
50.         if (GUILayout.Button("Color")) {
51.             currentColor++;
52.             ColoredGUISkinMobile.Instance.UpdateGuiColors(primaryColors[currentColor % primaryColors.Count],secondaryColors[currentColor % secondaryColors.Count]);
53.         }
54.         GUILayout.FlexibleSpace();
55.         GUILayout.EndHorizontal();
56.        
57.         // Text
58.         textValue = GUILayout.TextField(textValue, 50);
59.        
60.         GUILayout.FlexibleSpace();
61.         GUILayout.EndVertical();
62.        
63.         GUI.DragWindow();
64.     }
65.    
66.     void DoLevelWindow (int windowID) {
67.         if (windowID == 2) {
68.             GUILayout.Space(64);
69.             GUILayout.BeginHorizontal();
70.             GUILayout.Box ( "", ColoredGUISkinMobile.Skin.customStyles[2]);
71.             GUILayout.Box ( "", ColoredGUISkinMobile.Skin.customStyles[2]);
72.             GUILayout.EndHorizontal();
73.         }
74.     }
75.    
76.     void DoWindow (int windowID) {
77.  
78.         GUILayout.Space(64);
79.         GUILayout.BeginHorizontal();
80.         GUILayout.FlexibleSpace();
81.         toggleValue = GUILayout.Toggle(toggleValue,"Toggle");
82.            
83.         GUILayout.FlexibleSpace();
84.         GUILayout.EndHorizontal();
85.        
86.    
87.     }
88.  

EDIT: Just noticed I assign GUI skin each call will see if removing that helps.

EDIT2: No difference other than the skin not working properly

 

I've done mobile games using Unity GUI before, and they've worked fine. Yes it's draw call and CPU hungry, but for the typical GUI you'd use in a mobile game you don't need many of either of those things anyway. On older hardware (iPhone 3 and earlier, or thereabouts) where the draw call budget was much lower than on newer devices I expect it could be an issue, but our game was targeting iPod Touch 4th gen and better, and the GUI was not something we ever needed to optimise despite using Unity 3.5, where the GUI was much slower than it reportedly is now.

Regardless of which tool you use, success comes down to making sure that your GUI designer is equipped with whatever they need to get the right GUI made (be that the ability to code for themselves, a visual design tool, or having a coder on hand to work with) and knowing your performance, graphics and memory budgets. As long as you fit those budgets the internals of your tools are irrelevant.

I've used NGUI a fair bit and it can indeed allow you to make much more efficient use of your budgets or, alternatively, you can lower those budgets. It can batch far more stuff into far fewer draw calls and it better suits event driven programming. Overall it's actually a far more complex system than UnityGUI though.

For those saying that UnityGUI lacks functionality, consider that the Editor's own GUI is written in UnityGUI. It does have it's issues, and code-driven UI development is (quite reasonably) something that most people wish was left in the 90's, but as an immediate style GUI system it's not that bad, and they're quite well suited to some tasks. (Not the least of which is being able to chuck an OnGUI() method in whatever component you're developing and have it draw stuff straight to the screen each frame.)

 

The worst thing about Unity GUI is the massive garbage collection spikes it causes. Just a single OnGUI() call somewhere in your scripts is enough to give your game a nice "heartbeat". You can even see one of those GC spikes in JohnnyA's profiler screenshots, it's the big nasty brown one.

 

1. Its remarkably efficient.
2. Its easy to modify 'on the fly' in design mode.
3. It builds directly on the unity game object system.

NGUI directly leverages the advantages of unity to allow rapid development, to the point where the built in GUI is made to feel like the 3rd party add-on by comparison.

My most precious asset as a developer is my time and NGUI is incredibly time-efficient to use because of how well it supports GUI reconfiguration and tweaking. My direct experience has been that NGUI has reduced GUI development and refinement time by at least a factor of 5, compared to the built in GUI.

 

Performance and awkward scripting system apart, with the current Unity GUI you can't easily (at all) create 3D UI elements or other non-plain UIs. 3rd party solutions come to help here (I personally prefer 2D Toolkit rolled with my own GUI system), but they surely are more expensive than the initially-marketed-and-then-fallen-into-silence new GUI

 

This is an interesting perspective that I never considered. Have you evaluated Scaleform's UI? I don't know what their support is like, but Autodesk isn't going anywhere at the very least. Are long-term support concerns the only barrier for you regarding third party UI libraries?

 

I use EZGUI - and I'm old-school. Although it's got a lot of quirks, EZGUI makes Texture Atlases a snap, which is why I still use it. Unity's built in GUI is not quite dinosaur era, though it did feel like going back 15 years, to when my teams were first learning to build UI's in Java. Shiver.

Gigi

 

Although this is true, one can gain some certainty of a good third-party solution:

a) the Plugin is already supported a long time (in the case of this discussion: NGUI or EZGUI)
b) the Plugin itself is so advanced, it has build an own Community which could help if the original developers can't respond in time
c) the Plugin has a great documentation/samples, where the most stuff is self-explanatory

Personally I make some research on the support of the Plugin before buying, especially if the Price is above 50 €/$.
If I buy a complete new Plugin from an unknown dev and it's around 10 €/$ and the support discontinues after 1-2 months, I'll be sad, of course, but I guess one can take it. 10 Bucks don't hurt.

 

The ten bucks is irrelevant. What matters is the time we've invested integrating it into a project, and the time required to do it again with another solution if required.

For hobby stuff it's no big deal, but professionally using a package that ends up having poor or no support or being dropped could cost a project significantly.

 

The hardest to implement are:

- vertical scroll grid,
- list-view with multiple columns,
- comb-box with variable or changing contents,
- scroll-by photo with captions,
- localization of texts to variable-width word-wrapped length captions.

 

@eskimojoe Good list. Is that with Unity's GUI and/or others?

 

The top 3 contenders are:

- NGUI
- ScaleForm
- Neosis GUI


The only one that handles the above is NGUI, but it requires serious work. Just making a scrolling listview is really hard, even in both NGUI and ScaleForm. Scaleform is a bit screwy.


Neosis GUI you can check their beta.

 

I was just about to start a new thread titled "Why is Unity GUI so Bad??"

One would think if you could get 3D models to transform, move, and interact in 3D space with good performance, wouldn't it be just as easy (or easier) to get a 2D layer working just as well?? I mean, you eliminate a whole dimension, and at worst you could simply look at GUI elements as flattened 3D elements with 0 z-depth... so why on earth are there so many draw calls and garbage collection??

Anyway, just thought I would add my voice to the gripefest... I am brand new to Unity (started one month ago, and currently knee-deep in my first game, which is actually coming along pretty well), and feel kind of misled by the idea of OnGUI and GUI Layouts (things which are also touted in Will Goldstone's otherwise-excellent "Game Development Essentials" book), which both seem great in theory, but end up being so bad as to make me wonder why they are even offered...

Here's my growing wishlist for Unity (things which, really, feel like they shouldn't be too hard to offer as part of the base software instead of buying as assets):
1) Efficient, cross-platform 2D GUI
2) Efficient touch-screen actions (especially, for example, if you are just doing a single-point touch that mimics what a mouse-click would do... no reason you can't have easy "mouse-pointer" style touch interactions like button triggers or drag-and-drop)
3) Easier animation?
4) Built-in dynamic screen layout... many of us do it anyway (scaling elements to Screen.width, etc.), so how come this couldn't just be built in as a toggle or something to save time, to lay out by "percentage" or relative location rather than absolute, pixel-perfect? [would be even better if this could be done using containers like the GUILayout mode does... but in a device-independent and CPU-efficient way]

 

I would think Noesis GUI would far, far exceed NGUI's ability to handle any and all of the above. I've NGUI for a bit, and honestly I fund it cumbersome and somewhat clunky to organize, much less have a complex UI.Neosis GUI's XAML based approach to content is incredibly versatile.

 

Neosis is out on the Asset store now.


I did that during the time when Neosis was not available.

 

I have a confession; my motives weren't completely altruistic when starting this thread. Earlier this year my brother and I quit our jobs at Samsung to make UI middle-ware (we got tired of hacking out touchwiz versions.)

We're getting close to being ready for a closed beta. I'm coming from the mobile app industry so I have my own list of "really ui toolkit?! Who thought this was a good idea?" - I started this thread hoping to get others' lists.

You can get a peek of how I'm trying to fix UI at uiink.com

Beta is still a few months off, so let me know if you'd like to be in it. Also which platforms you'd want tight integration with first.

And @guru20, that's a good start on a list; putting what you want into words goes a long ways towards making something happen.

 

this

 

@Cake: looks very interesting, and kind of what I'm hoping the new Unity GUI will be

 

@Izitmee That's what I was going for

 

Please don't make your system use an external library at run-time (.dll), de-facto killing Web Player export capability. I find Neosis to be pure genius but I cannot use it for the Web Player.

 

If the DLL is just a regular external library there is no problem at all with webplayer exports. I work with many DLLs, since I like to pack reusable code in separate libraries, and I also create a separate assemblies for all the project's code since I prefer it like that, and webplayer has never been an issue. Also, Unity itself creates an external library with your code, in case you're using lose scripts

P.S. I didn't look into Noesis, but maybe it uses a C++ library, or some C# stuff that is not compatible with the webplayer

 

http://answers.unity3d.com/questions/473921/unity-webplayer-and-dlls.html

Yup, so if it's not built as a managed .dll with the accepted .net classes it won't work. Also, the whole problems with security people going all crazy when you tell them there's a .dll in your web package... but that's another story.

 

DLLs (at least, managed DLLs) shouldn't be a problem for security people in case of Unity plugins, I hope, because DLLs can be read and inspected for threats as easily as lose scripts, even with free decompilers. For webplayers instead, Unity itself makes DLLs, and unless I'm wrong (which I might be) antiviruses don't care about other DLLs unless they contain some reference to less commonly used (or "dangerous") NET libraries.

 

To start with, Unity Pro will probably be required. Some features, such as complex text layout, will always need native code (freetype and harfbuzz, neither of which I was able to compile to CIL bytecode, which is needed to support Unity free).

The web-player requires all bytecode to be "safe." I've experimented with a gcc backend that outputs CIL, and it does work for targeting the desktop with Unity free - sadly the output is definitely not "safe" code. It's still a "managed DLL" - just with unsafe operations that the web player blocks.

I do have a few ideas for supporting the web player, but it likely won't be available until after the beta.
Chrome native client shouldn't be a problem to support though (which I imagine a lot more people have than the unity browser plugin).

 

UnityGUI doesn't work for me for a number of reasons...

1.) Draw calls, of course.
2.) if {} else { if {} else { if {} else { ...
3.) I can't see what I'm doing.
4.) Even after I've written a designer on top of Unity GUI, event support is still broken (seriously, the bottom-most control gets the mouse event before the top most control?? WTF?)

I also used NGUI for quite some time, but never really liked it. Often it felt like I was fighting NGUI to get the result I wanted, and in some cases I just had to punt on something because there wasn't a good way to do it in NGUI.
Lately I've been using DF-GUI and am quite pleased with it. Similar features to NGUI (one drawcall, super efficient, etc), but feels a lot more like WinForms than NGUI does, although of course it can easily be used for HUDs and such. I'm also quite happy at the textbox support, which is far better than NGUI and a lot closer to UnityGUI (you can actually select text, move the cursor around, and on some platforms you can even copy-paste).
It's also a fair bit cheaper than NGUI.

 

There is also PrimeToolkit, but it takes a bit of effort to make something.


Unity 4.xx with non-existent new GUI feature...

 

1. You get 30 to 100 draw calls, more like 500 draw calls after a complex GUI is made
2. Did you try using switch/case statement?
3. Did you try [ExecuteInEditMode] tag?

 

NGUI is out for $38 (60% rebate on $95 full price) as the daily Summer deal in the Asset Store.

Just wondering if we can expect the new Unity GUI at Unite 2013 next week ........ :twisted: