Performance for separate Inspector Window is really bad with odin

[Johannes Deml]

I created a script with which you can open up any ScriptableObject in a new inspector window by double clicking it. You can find the script here and here.

Somehow the performance of odin is terrible in those. The OnGUI is basically just doing that:

scrollPosition = GUILayout.BeginScrollView(scrollPosition, GUILayout.Width(width), GUILayout.Height(height));
            {
                editor.OnInspectorGUI();
            }
            GUILayout.EndScrollView();

Any thoughts of why the performance is so bad? I didn't have those problems prior to installing odin.

[Tor Esa Vestergaard]

Using your scripts, I just opened a dozen windows and saw no performance issues at all.

Can you perhaps try running the profiler in the editor (possibly with deep profiling enabled) and seeing where the bottleneck is, or give some example ScriptableObject scripts that cause this problem?

[Johannes Deml]

Hm, very interesting that it doesn't create any problems for you. I recorded the lags and unresponsive animations: https://youtu.be/eycPel8A3Jw

The scriptable object Code looks like this (Simplified version):

public enum QualitySetting
    {
        None = -1,
        Blazing = 0,
        Pretty = 1,
        Stunning = 2,
    }
[Serializable]
    public class DeviceNameMapping
    {
        [HorizontalGroup("FirstRow")]
        [LabelText("Device")]
        [LabelWidth(60f)]
        [Tooltip("This is just for us to know which device is meant")]
        public string DeviceName = "iPhone SE";

        [HorizontalGroup("FirstRow")]
        [LabelText("Quality")]
        [LabelWidth(60f)]
        public QualitySetting QualitySetting = QualitySetting.Pretty;

        public string[] DeviceModelNames = new[] {"iPhone6,1", "iPhone6,2" };   
    }
[Serializable]
    public class IosDeviceSettings : IQualitySetting
    {
#if UNITY_EDITOR
        [SerializeField, TextArea(3, 10)]
        private string notes = "";
#endif
        [SerializeField]
        private DeviceNameMapping[] devices = null;
}

I also deleted all entries from that scriptable object and I do notice quite a performance drop (as for animations and responsiveness).

Here are my computer specs if that is of any importance: Graphics card: Radeon 7900

[Tor Esa Vestergaard]

Is the performance of these objects also really bad if you just look at them in the regular inspector rather than through editor windows? It's definitely only bad performance when they're rendered in windows like you're doing? (your approach there looks entirely fine to me, by the way)

[Johannes Deml]

Thanks for your response! As you can see in the video starting at second 44 (https://youtu.be/eycPel8A3Jw?t=44s) the animations are not existent in the custom editor window, but work just fine in the inspector. I also tested disabeling odin inspector for that file type. The custom editor window had no problems then. So it seems that something makes odin really unhappy with my solution, but I really can't tell what it is (Could it maybe be the scrollView? ).

So yeah, as for your question. The performance in the inspector is good. I used the inspector for the very file I'm showing in the video for at least 20 minutes yesterday to fill in the data and had no performance issues. So do I get you right, that you're not able to reproduce the problem? :S

[Tor Esa Vestergaard]

Hmm. As an experiment, try adding "this.Repaint()" at the very end of ScriptableObjectInspectorWindow.OnGUI, and see if that has any effect. It's just a theory, but... it might be the case that repaint requests are not happening properly for you, and that's why it feels stuttery. Alternatively, it will make performance even worse. It's either-or!

[Johannes Deml]

Wow, okay... Yep, that works. Right now I'm really impressed how you managed to point in the right direction without having the possibility to test it yourself. This did really fix the problem! Would you say this is still kind of hacky or should it be just fine? I guess this way the window will do a redraw at every ongui, even when it is not focused, right?

[Tor Esa Vestergaard]

Lucky guess! :D

To prevent constant, non-stop repaints and only repaint when necessary, try adding the following code instead of the plain Repaint() - that should do the trick:

if (GUIHelper.RepaintRequested)
{
    this.Repaint();
}

( GUIHelper is an Odin utility class, so you'll also need to add "using Sirenix.Utilities.Editor;". )

Though this works, our repaint requester really should just magically locate the current window and request a repaint on that if it's not an inspector window, as the Editor.Repaint() that we have been automatically invoking so far only really causes inspector windows to be repainted, I can see from looking at the decompiled Unity code.

[Tor Esa Vestergaard]

Actually, I just made that change to the code - turned out to be very simple - so I'll mark this resolved. It'll be in the next minor patch of Odin.

[Johannes Deml]

Cool thanks! So in the next update odin will always run the code you just pasted on the active window? Awesome thanks a lot for the quick responses and for sticking with me on this

[Tor Esa Vestergaard]

Yeah, in the next patch calling editor.OnInspectorGUI should cause the current window to repaint if that is necessary. And no problem! Happy to help.

[Johannes Deml]

Awesome! Thanks for your excellent work!