Even if you preload a scene async AND start with all gameObjects disabled in the next scene, there is still a significant freeze in between scene “A” and scene “B”.
During this freeze time, if users click on the screen (or onfocus + refocus), Windows will bring up a “this program is not responding [WAIT / END TASK]” false positive:
How to prevent this?
We’ve tried every async loading trick in the book, but we can’t seem to prevent this freeze.
(We use 5.6)
In the following Unite Talk, Playdead presents their “Time Slicing Awake” technique to spread expensive scene activation tasks across multiple frames to avoid freezes.
The Time Slicing Awake talk starts at 9:50
I dont have access to the unity source code, nor would I have time to change the integration phase of a scene load to a timesliced approach.
What is the point of having async scene load at all when its not 100% async or time-sliced for the parts where its not possible.
When the game is stuttering then you need to have a real loadscreen anyway.
Is this something that will be adressed in 2017.2 ? @SteenLund
What can we do to not get any hickups when loading scenes asynchronously? (granted, 500ms+ is a little more than just a “hickup”)
I tested loading different very small scenes in the editor, as well as in a built executable.
Everytime “Application.LoadLevelAsync Integrate → Loading.AwakeFromLoad” is taking a really long time.
That Playdead talk is great, thanks for linking that @Peter77 ! It really shows that because Unity is such a general purpose engine, when you want to hit 60 fps and have a buttery smooth consistent experience you have to really work at it and build a lot of specific tech for your situation. A lot of the things we would do in custom engines still applies. A lot of projects I’ve been brought onto as a contractor have been built in an adhoc way, and assume that Unity will handle everything like culling and performance. It’s frustrating when that happens because it’s hard to change a project that is already established and has a deadline!
-sam
> and assume that Unity will handle everything like culling and performance
^ These two comments!! I know right! It’s stuff like this that drive me crazy. Unity says “Hey here’s a new feature!” then completely abandons it, pretending it’s stable (Remember UNET? Or when 5.6 launched and completely broke FB standalone due to lack of testing when implementing FB Gameroom?) to load other fluff features in a new version, leaving the old (yet ESSENTIAL) stuff high and dry. Can you imagine that we’re almost in 2018 and loading scenes async with Unity creates false-positive FREEZES in Windows? It’s insanity (and embarrassing) that that artist tools are being focused instead of finishing beta-like features __ and fixing their major bugs __.
**> Is this something that will be adressed in 2017.2 ? @SteenLund **
Looking at dominant Unity patterns, Unity only fixes NEW features. This would be nice, but I wouldn’t hold your breath. Some of the biggest bugs and requests in Unity that have been here for countless years are either still not fixed or completely ignored.
Still waiting for the day that Unity holds a bugfest (+finishing old features) Hackathon to move out from this “Windows Vista” state 
Apologies for my rant, but man…
Dude, its enough, HOW DO I GET A LOADING SCREEN TO WORK IF IT IS FREEZED!
Please do not necro post like this. Check the dates of posts, especially if you’re going to necro and go full-caps. 
Let’s close this thread.