Cost of OnGUI call

Unity Engine
1

Hi, I am currently busy creating a solid and clean GUI system for my project.
I have for now chosen to use the native unity GUI.

I was wondering how much each GUI call costs me, even if nothing happens within that gui.
Would it be a better idea to have 1 OnGUI() call and have that function distribute the calls to the various active GUI scripts, or does it not matter that much?

Thanks in advance

2

It’s usually best to keep everything to a single OnGUI method if at all possible. Makes it easier to keep things organized and, at the very least, reduces your method invocation overhead (every OnGUI method is called twice per frame - once to paint and once to handle events).

3

It’s worth noting that OnGUI can wreck havoc on your performance, especially on smartphones. Amongst other things it has a tendency to incure large garabage-collection spikes on low memory devices. Most people use a third party solution.

4

I was using OnGUI before and read much about how it affects performance.
I then switched to NGUI, which is event driven and not cycle driven, which is
why it is so much more efficient than OnGUI. OnGUI is like an Update()
which also hits performance, so reducing both of those methods to as
little as possible is your best bet. Even removing empty Update()'s
can help a slight amount.

5

What platform are you running on, what kind of application are you making, and what does your GUI actually have to do?

Despite how much people go on about how bad it is it might not be an issue depending on your intended usage.

Did you switch because you read about bad performance, or because you were actually having performance issues?

6

Well, the existence of OnGUI method (same as FixedUpdate, Update, LateUpdate etc.) will add a small overhead (because the Engine has to call it in certain intervals).

But you basically have two main issues (beside it being slow and anno 1990 :P) with the OnGUI

  1. If you put everything in one single script, it will clutter pretty fast
  2. If you do everything in their on respective OnGUI calls, they are not aware of each other.

The later one can be an issue, if you i.e. pop-up an window and you want the buttons in the background to be disabled, so that the clicks don’t “go through” your current UI, which can be an issue for more complex UIs

7

Thanks for all the input guys!

@angrypenguin: I am currently working on a prototype of an RPG game. So i will be doing quite some GUI things for inventory, skills, HUD and what not. The target platform is PC Mac (and who knows, Linux too :slight_smile: ).

@Tseng: I hate to put everything into one single script. I have solved the problem of the second point through a GUI manager. All GUI scripts register themselves with the manager on start and every gui can easily find another by asking the manager.

What im trying now is to have the manager be the only one with an OnGUI call and call a method on the other active GUI’s.

I have done some profiling and noticed that right now, with around 6 scripts with an “empty” OnGUI call (all they do is check if active is true, but its false on every one of them) creates roughly 5kb of Garbage Collector allocation. After changing the calls to manager only the GC alloc has gone down to 1.5kb, so the change is quite substantial.

8

I think I have quite the same problem as here (so I am not creating another thread).
The profiler of my new game indicates that 35% of cpu is used on a single OnGUI call.

As I need a custom keyboard, I made one with one GUI.Button per key stroke (~30)…
I tried everything to speed up processes, storing all procedural stuffs, keeping only the display on OnGUI like this:

void OnGUI(){
foreach(KeyValuePair<string, Rect >kvp in KeyboardLayout)
{
		if(GUI.Button(kvp.Value,kvp.Key,this.keyboardStyle))
				this.CurrentBuffer+=kvp.Key;			
}
}

I have to clues to speed things (and I can’t use native keyboard of devices). If anyone have something in mind, that will be very appreciated !