Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Can UT provide more efficient GUILayoutOption?

Discussion in 'Scripting' started by WillNode, Jul 17, 2018.

  1. WillNode

    WillNode

    Joined:
    Nov 28, 2013
    Posts:
    423
    Just peeked on GUILayoutOption source, and I'm been thinking about the code a while...

    Code (CSharp):
    1.     public sealed class GUILayoutOption
    2.     {
    3.         internal enum Type
    4.         {
    5.             fixedWidth, fixedHeight, minWidth, maxWidth, minHeight, maxHeight, stretchWidth, stretchHeight,
    6.             // These are just for the spacing variables
    7.             alignStart, alignMiddle, alignEnd, alignJustify, equalSize, spacing
    8.         }
    9.         // *undocumented*
    10.         internal Type type;
    11.         // *undocumented*
    12.         internal object value;
    13.         // *undocumented*
    14.         internal GUILayoutOption(Type type, object value)
    15.         {
    16.             this.type = type;
    17.             this.value = value;
    18.         }
    19.     }
    There's two things that I don't understand about this piece of code:

    1. Why it is a class? Doesn't then every time we call GUILayout.Width there will be GC overhead involved? I think it's more sense to use struct instead.
    2. Why GUILayoutOption.value is an object? If I understand correctly, all GUILayout props are using float. This object conversion only makes excess overhead due to boxing and unboxing primitive values.

    I failed to see any reason why GUILayoutOption implemented that way (maybe historical reason?). Also,
    I don't think that optimizing this code with my theories above will make any breaking changes, anyway.

    I filed this in feedback too: https://feedback.unity3d.com/suggestions/make-guilayoutoption-efficient
     
  2. mjzx

    mjzx

    Joined:
    Aug 18, 2013
    Posts:
    114
    I personally don't think it should matter too much, as these IMGUI are usually used for the developer of the game instead of the consumer, as stated here: https://docs.unity3d.com/Manual/GUIScriptingGuide.html
    So it shouldn't affect most final builds of any games developed with Unity3D.

    Also, why would there be GC overhead when calling GUILayout.Width? GUILayout.Width is static, so there wouldn't be any continous instantiation. (Correct me if I'm wrong)

    I believe the reason they use an object for value would just be to keep things easier if they ever needed to use a different value type.

    Yes, technically, it is a slight optimisation, but it is also a little less convienient for the developers of this system if they were to implement your suggestions, in my opinion ;)
     
  3. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    There's a ton that could be done better with how the IMGUI stuff is done, both from an optimization standpoint and a coder quality of life standpoint. Unity's probably not doing anything about it since they're making a new framework for creating editor UIs, that's going to ship early 2019. It's based around a css-like idea for styling. They haven't started showing it off yet, but it was mentioned as definitely coming out in Unite Berlin, and you can try to use it (without documentation or examples) by digging through the experimental namespace.

    I believe it's what's used for the new material editor.
     
    xVergilx likes this.
  4. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    Other than that, all those layout calls are missing shortcuts.
    Like why there's a need to write EditorGUILayout.X() each time, when it's possible to trim that down to X()?

    Scopes can be trimmed down to simple:
    Code (CSharp):
    1. using (Vertical) {
    2.   // ...
    3. }
    via inherited properties.

    Not to mention GUI/GUILayout naming issue.

    Had to write a custom class that inherits from the Editor/ScriptableWizard to hide all of that, and it did simplified my editor code a lot. I mean, like A LOT.

    You can do with that kind of stuff.
    Like recording and modifying state of the object without SerializedProperties that supports Undo, etc.

    Unity is weird sometimes. Backward compatibility probably. Or simply laziness.
    Nobody cares in UT about how an actual editor code would look like, unless it's their own internal stuff.
     
    Last edited: Jul 17, 2018
  5. WillNode

    WillNode

    Joined:
    Nov 28, 2013
    Posts:
    423
    I agree. It's not a big deal, but I really think it helps when writing quick prototype games. Maybe the cost to break simple things that worked all the time is really high than that.

    I really hoped that this new UI is not a wrapper for existing GUILayout. Although, yeah, most likely it will be an editor-only feature (I really hoped for runtime support).

    Yeah, it's kinda verbose to write IMGUI layouts directly. I have my own snippets that handle common GUI scenarious all the time. I just wish that somebody can write some easy abstraction for that :confused:

    (Btw, that using Scopes is quite evil and brilliant ;))
     
    Last edited: Jul 17, 2018
    xVergilx likes this.