0
Fixed

'Tabs.AnalyzeWindowLayout' causing lag in game view.

RyanL 1 month ago updated 1 month ago 4

Hi there. Using Peek 1.2.0f2 (already upgraded from 1.2.0f1, thanks for the quick response), I've noticed that 'Tabs.AnalyzeWindowLayout()' is taking a considerable amount of time in my main project, specifically 'Resources.FindObjectsOfTypeAll()'. 

In a new test project with only cubes, the time taken by this function is imperceptible. However, in my main project, the function is taking up to 18+ ms per frame according to the deep profiler while playing the game in the editor. See the attached screenshot.


I suspect that the call 'Resources.FindObjectsOfTypeAll()' isn't scaling well with projects that have a lot of resources? Such as it is, returning from this function while in gameplay by inserting this at line 77 in Ludiq/Ludiq.Peek/Editor/Tabs/Tabs.cs acts as a patch that is sufficient for my needs:

if (EditorApplication.isPlayingOrWillChangePlaymode) return;

Thanks.

Unity Version:
2020.1.6f1
Peek Version:
1.2.0f2
GOOD, I'M SATISFIED
Satisfaction mark by RyanL 1 month ago
Working on Fix

Hi Ryan,

Thanks again for the detailed report and I apologize for the performance issue.

I'm looking into this right away.

The issue is that, as far as I know, Unity has no event to let Peek know that the window layout has changed, which we need for setting up Tabs, so we need to poll it pretty much constantly.

I'll try to be more clever about that. Ideally, this function wouldn't run every frame, even in Edit mode. Your hotfix sure will help in Play mode, but I'd like to avoid a performance drop even in Edit mode.

Fixed (Unreleased)

Hi Ryan,

I've figured out what I think is a clever way of detecting potential window layout changes. In the next version, I'll only analyze the window layout if the active window changes, or if it gets maximized or minimized. This should make the check punctual, not at every frame, even in edit mode.

The code will roughly look like this:

        private static void WatchWindowLayout()
        {
            var focusedWindow = EditorWindow.focusedWindow;
            var isMaximized = focusedWindow != null && focusedWindow.maximized;

            if (focusedWindow != lastFocusedWindow ||
                isMaximized != lastFocusedWindowWasMaximized)
            {
                AnalyzeWindowLayout();
                lastFocusedWindow = focusedWindow;
                lastFocusedWindowWasMaximized = isMaximized;
            }
        }

Thanks for the fix in v.1.3.0! The performance issue has been resolved in my main project.