what's the exact difference between GUI and GUILayout

in the reference,it said "The GUILayout class is the interface for Unity gui with automatic layouting."
dose that means GUILayout is only design for automatic layouting? Belongs to GUI？ and when to use GUI or GUILayout more properly?

 

GUI and GUILayout basically do the same thing. All the controls that you create are identical in both.
The difference is that with GUI you have to give an absolute location and size of your controls.
With GUILayout you don't do that. Unity organizes the control positions automatically. How Unity does this can be defined by methods like GUILayout.BeginVertical, GUILayout.BeginHorizontal and GUILayout.BeginArea (just to name the most common). Also you can set desired button sizes, etc.

I almost always use GUILayout, as it makes adapting to differenz screen sizes relatively easy.

 

In addition to what Der Dude said, I've noticed that GUILayout and the manual GUI function vary in CPU usage.

GUILayout tends to take approx 2x as much CPU as GUI even when I'm calculating text sizes for the standard GUI function. GUILayout tends to take 3x to 4x as long if I use a GUILayoutOption at the end of it.

I figured this out by using the Profiler.

So, you will sacrifice some performance if you go with the GUILayout function which may or may not matter depending on the CPU intensity of your game.

Hope this helps
Nathan

 

it helps a lot ,thank you all.

 

Thank you for that piece of intel.

 

This is a very old thread. If you want to create a UI for your game, it makes more sense to use the new Unity UI instead of the the old OnGUI functionality.

 

GUILayout is killing performance on my Android device. I tried using the new Unity UI for our app and it did not work well showing numbers that update every frame. My plan is to replace all my GUILayout code with GUI and hope that solves the choppiness I'm seeing. Thanks for the benchmark, NathanWarden.

 

Could you elaborate on this? The new UI works just fine for updating numbers every frame (and is leaps and bounds faster, performance-wise, than either GUI. or GUILayout)

 

For the new Unity UI, if you're experiencing performance issues on mobile, you may want to switch to a mobile shader or use jonbro5556's shader, which he posted here. Also make sure you're not disabling and re-enabling your UI element(s) or deactivating and reactivating their GameObjects, as OnEnable can be a little expensive, especially if your Text elements have Best Fit ticked. But, generally speaking, Unity UI will outperform legacy GUI, so you might want to look into it again. Also review the Unity UI Best Practices post.

If you decide to stick with legacy GUI, keep in mind that OnGUI will be called multiple times per frame, so minimize what you do in it. For example, don't compute Rect bounds each time OnGUI is called; instead, compute it elsewhere and use a cached copy. And certainly don't do any kind of string manipulation (e.g., GUI.Label(rect, "Score: " + currentScore)) because this will generate garbage every frame, causing GC spikes.

 

It's been a few months since encountering the problem, but from what I can recall the problem came from trying to display data from iOS core GPS services. Occasionally the text in the UI elements would become garbled and unreadable, sometimes correcting itself after a few seconds and sometimes not. We weren't able to figure out the cause before just using legacy GUI scripting.

 

Does this still the case in current versions of Unity?

 

If you're using this GUI system, yes; but you shouldn't be using this system except for editor code (and even for that its days are numbered). For in-game UI you should be using the Canvas-based system (called UGUI) instead, which is a completely different thing.