Different issue, it seems, but also related to the UI overhaul. I’ll have some panels open on the side of my studio window like the Toolbox and Asset Manager, and when I collapse them Studio starts lagging extremely hard until I expand them back out.
Also, if I have a script open in the main window, Studio will lag a bunch until I pop the script editor out into its own window. I’ve had lag issues relating to the new UI since last week and it’s been very frustrating.
Are you using an Nvidia G-Sync monitor?
Yeah, these were recorded on my main monitor with G-Sync enabled. I actually noticed after I posted that these issues didn’t occur when I had Studio open on my second monitor, which doesn’t have G-Sync. Seems like disabling G-Sync when Studio is open via NVIDIA Control Panel fixes the issues as well, thanks for the reply! It’s still a really odd bug though, I hope that gets fixed soon.
I’ve had the same issue before, and the workaround is to change G-Sync to fullscreen mode.
Have been experiencing some issues as well where Studio had to restart due to the issues.
This image below shows two of my DOCKED windows are bugging out. They are in position according to Studio
This image below shows the two windows from the image above popped out of Studio and NOT DOCKED for some reason.
I do not know how to repro
This is likely not the docking issue… it looks like the 3D view not getting updated properly. Did this happen when you hit Play or Test?
No, it happens if you change a window layout too quickly, mostly opening/closing plugins, it happens most of the time after I finish playing, but it might be because all of the windows reload when the game stops, it’s probably because it’s not updating the 3D view as it freezes and it’s not cleaning the old frame rendered so the texture just gets redraw again, I think that because you can see a similar effect if you resize the 3D window too quickly, the FPS drop a lot (not the problem) but the window next to it (the explorer) gets drawn multiple times probably because the 3D window and the explorer window are not rendering at the same framerate so it doesnt update and cleans the old frame
Edit: When this happens, the 3D window actually gets separated to another Windows Tab but you cant change to it or use it
This is what I mean
I can do that to my studio as well, but I don’t have the numerous docking/window issues. I don’t think that one described in the video is a bug.
The 3D view not updating means the 3D view crashed or is unresponsive.
I never said it was a bug, I said that I thought about the 3D was not updating because it freezes as you can see a simlar result when FPS drop
A fix for blank/non-updating 3D view during Play/Test was released this morning. Let us know if you’re still having issues with the latest Studio.
Thats not true. This bug is indeed caused by QT docking widget corruption.
When the main window (the dock widget that is never undockable ie. it always stays on the main window) corrupts and is force seperated to another window, the main part of the screen is not rendered by QT and this any leftovers of other QT widgets being rendered are left.
The bug isn’t that the main widget does not update, the problem is the layout corruption. The leftovers from others QT widgets are just a side effect of the main window not updating.
Here is an example of this happening due to layout corruption:
This has happened to me multiple times which is quite frustrating. (Also I’ve purposesfully in this example resized the window during the corruption to showcase the effects of QT widget leftovers)
This has usually happened when I have 2 different studio games open. When I open another game and the second window tends to have it’s QT widgets forcefully seperated to an outside window.
Fixing non main QT widgets is as simple as closing the QT widget via the “x” button and then resizing the layout.
But no such thing works for the main QT widget (which has the 3D view).
TLDR; The main 3D view not being rendered is a fault of QT widget layout corruption because it’s forcefully rendered in a different window.
OK thanks for the additional information. Last week we were particularly focused on the main 3D viewport stopping it’s updates when Play/Test is entered (we cleared it up for most people and another fix going live for that this morning).
Your screenshot only shows the main view not updating so I assumed it was related to that. But you’re not in Play/Test and I assume resizing the main window doesn’t bring it back.
It’s a top priority to overhaul all of the window and docking code to finally eliminate the root cause(s) of the docking corruption problem(s). It’s difficult to explain why this has been such a long running issue and why it’s a difficult task. But trust me, we are all just as tired of dealing with it as you are.
I did not take a screenshot of the other window but I can guarantee the cause is dock widget corruption.
The main 3D view was in a different window and was totally functional so the issue wasn’t that it wass not updating, but that the widget is rendered in a seperate window due to QT dock widget corruption leading it to be in a seperate window.
The other widgets which were not the main widget were corrupted and rendered in a different window also, but I was able to fix them by clicking “x” and resizing them after that.
I couldn’t fix the main window with the same method because it couldn’t be closed and re-enabled.
Understood. We plan to bring back 3D view dock controls with the window overhaul.
There’s an issue with plugin menus, they’re always stretched and rescaling does not save.
(Any plugin)
We have been working on it as a priority. It’s not a simple fix we’ve been ignoring — it’s taken a very long time to reproduce and root cause the actual problem. There is a small update:
Late last week we had a breakthrough and we have a pretty good confirmed idea of the actual issue (no surprise it depends quite a bit on the machine config Studio is running on which is why we’ve had a such a tough time reproducing and also why only certain people experience it frequently)
I’m working with the team today on what it will take to get a validated, permanent fix out ASAP.
Had this happen to me today, the viewport can still brick itself sometimes:
Thanks for sharing the video. Yes we are continuing to work on the docking issues and we are aware they can affect the Start View as well. The team has made progress on identifying the root cause(s) and reproducing the issue. This remains a top priority to make a permanent and robust fix — we have dedicated folks working on it.
