![]() ![]() If we now process OS events in parallel instead of in-sequence, we will be displaying potentially incorrect info to the user. However, this is not simply a technicality. The only solution I can image is to put all these calls on another thread to avoid blocking the UI. So point 1 will be addressed, but point 2 is a whole category of issues that are extremely challenging to deal with. We check which window it is, and here the OS call blocks, as unity window is frozen. The issue again being that when the OS event arrived, we see that a window was focused. We track these things to keep track of the order of recent use of windows in AltTab. This triggers an OS event letting AltTab know that the user focused the unity Window. The example I faced during my tests is switching focus to another window, then back to the frozen Unity window, as you have suggested. I added it to hopefully prevent Phantom windows created by app Optimus Player #200, but it was not a clear need, so I'll remove until other people open tickets about buggy windows being displayed (hopefully not □). For this one, I'll just remove that code. This is why it is freezing globally when using AltTab when the unity window is frozen. When invoking AltTab, we check all windows. There are multiple scenarios where this issue happens: There is no easy fix to this, as we have simply no way to get the info we need until the Unity window stops freezing. These calls happen on AltTab main thread, thus freezing it. When we ask the OS for some info on the window, the OS blocks the calls until Unity is no longer busy and responds. The Unity window that's recompiling was frozen, as proved by the fact that the mouse becomes a spinning wheel on that window, while it's recompiling. There are 2 distinct issues, that can both be generalized as such: I installed Unity, downloaded the sample project you shared, and after a few other steps, I was able to reproduce the issue! P.S.: My recommendation is to use a reasonably complex project to make sure the recompilation takes enough time to test this out. Maybe it's all the same issue and here it's just simpler to replicate? I've seen a few other issues that seem to report a behaviour where AltTab stops responding. This looks as if AltTab "grabs" itself to the current process and becomes unresponsive until that same process is responsive again. ![]() AltTab into Unity while the reimport is still happening, and you will see that AltTab stops working until Unity finishes compilation.AltTab into any other program and see that it works as expected.Right-click a code file (C#) and select reimport.The rest of the OS is responsive while Unity is compiling and AltTab is not affected unless we "land" on Unity while the compilation is happening. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |