Lots of busy... Hold on.... etc?

Just wondered if these will go away? present in 23 and 24, or if it's something I'm being incredibly naughty about in this relatively slim project...

 

It's intolerable, I guess it might be collab or something, will try rolling back.

 

I’m getting them too (and also using Collab, but I’m not convinced that’s the reason)

 

Are you talking about the "overhauled" progressbar that displays "busy for" now:



I like the idea of displaying progress! I mean, I prefer seeing an indicator that Unity is busy, rather than an editor freeze with no feedback.

That being said, I would of course even more prefer if Unity would be fast, so I don't have to stare at "busy for" and could actually work.

PS: I see this progressbar with "busy for" for a lot of things in Unity, like opening project, opening scene, enter playmode, etc. That's a nice improvement for me



I would also prefer if it display "Please wait" rather than "Hold on", but I guess they have way more important things to do

EDIT: A nice improvement would be if that "Hold on" progressbar would not appear immediately, but after 500ms. That would workaround issues where things are fast, so you don't see a progessbar for operations that finish in a split-second, thus being easier on the eye.

 

i'd hope that it can be toggled off..

when working with some small test projects it gets annoying to see that box flashing for 0.01s every time..
and its so fast that you cannot read anything there anyways..

also if you alt tab away after you press play, then whole unity starts blinking in taskbar..

 

Agreed.

I had the same problem in several tools I wrote too. My solution to this problem was to display the progressbar only if the operation lasts more than 500ms. That removed all the progressbar flashes and only showed progress for operations that actually took longer, where showing progress is then useful.

Perhaps Unity could implement this too.

 

But these things... weren't taking up time before at all.

Basically I stopwatch timed it from the earlier version and this stuff is additional time added for 0 reason. It's much slower/more disruptive so I had to post.

I mean even switching to another window (0 saving, 0 compiling), it pops up this stuff and makes me wait for 5 sec where before, zero wait.

Honestly, if it goes live like this, then 2019.3 LTS will do I think... hoping its just other packages or something causing it.

 

While liking the progress bar addition I've noticed more waiting around too

 

It kicks in whenever anything happens. Even clicking an object will trigger it sometimes, it's a bloody nuisance. It's probably automatic, and if so I'm wondering why. I'd love to know why in an age of multi threading, this thing would happily block things that weren't blocked before.

Don't see a single thing I like, or even need to know. I mean getting used to a cog or discreet progress bar in corner is way preferable.

 

I mean, I don't know. What am I supposed to get out of that?

I now know that Unity spends a few seconds randomly in Application.Tick , Application.Messages and SceneTracker, and also I used to say that "Checking for Changes" took a couple of minutes, but now I know it's over 3 minutes.

And with all that information I now also know that in the time it takes for my project to open in 2020, I can open and close the same project in Unity 4.x around 100 times, which feels... ...

What am I supposed to do with that information?

If I was any more negatively predisposed against Unity I would say it's some sort of bizarre power move ("LOOK WE ARE MAKING YOU WAIT AND THERE IS NOTHING YOU CAN DO, HAHA")

 

I have the same issue.
It's bad on 23, but it got unusable on 24 so I rolled back to 23 for now.
Using AssetDatabase.SaveAssets() after dirtying a single tiny ScriptableObject takes almost 20s on 24, and takes about 10 on 23. Looking at the profiler in 23, it goes up to 2.5GB RAM (!) to run SaveAssets()

Before, it was nearly instant. Something definitely happened in recent versions.

---

Found the culprit for my case: QuickSearch 1.6+.
1.5.2 is fine, but 1.6 is sorting a very large array or list and is causing all this. Will post on its threat soon.

 

That's a good point, I would prefer it too.

What I get out of it is that I can see that Unity didn't freeze, but is still doing stuff. I often had the issue: "Alright Unity, you locked up for a minute already, you dead?".

Probably just a bug.

If it's related to the progressbar and I have to guess, I would say the progressbar is updated every iteration of work, rather than in timed intervals. I wrote a blog-post how updating a progressbar often makes your program significantly slower and show solutions that don't suffer this issue:
http://web.archive.org/web/20160804220745/http://console-dev.de/?p=447

 

There's no bug. Or if the're a bug, it's like for an extra 30% difference in slowness.

I've gone from being able to open my project and do work in a few seconds with Unity 4.x and Dropbox to a few minutes with Unity 20XX and Collab.

But in any case, we're getting off topic, since these are not specific to 2020.

I maintain that unless I can do something about it, letting me know (in a shortly flashing panel that I may or may not have time to read), that Unity is wasting time for Application.Messages is absolutely useless.

 

It would be better if the progress bar is part of the editor and not a popup.

 

Well, if it's non-responsive for 1.1sec the dialogue will appear for 0.1sec, making it seem to us like it's flashing and popping in and out.

So the question is, why is the Unity editor non responsive for longer than 1 second so often.

 

We have objects that rebuild the mesh and this takes no time at all. We also use raycastcommand jobs from time to time.. I don't know if it's relevant or not.

Without this feature there is 0 delays.

With this feature we are being delayed! big time. I think you should make it 100% optional so I can entirely disable it. "Unresponsive" editor detection seems totally broken here.

I mean, I get it pop up and delay me for 2-5 sec just because I clicked away from the shader editor window to the scene view. That doesn't sound right at all.

It occurs when I'm also doing nothing at all! Got no choice due to work deadline need to roll back, but please make the feature optional at least.

I'm not sure why it is automatic either, surely a developer is best off subscribing to this system on a need-basis. Having it always running seems like a point of failure.

 

with default empty scene, it appears for about 1.2s, which is still so fast that you cannot read anything (so its not useful in that short time).. i'd prefer if its possible to disable it. (can be useful for debugging hangs, but in daily use would get annoying)

 

My tool will *also* trigger it, but only sometimes.... as if editor is GC collecting behind scenes. It rebuilds a mesh and material) as I move a slider. Without this feature, it just slows the editor down to 30 fps worst case scenario without this feature.

So I don't think editor is detecting its unresponsive time correctly, and even if it did I don't want it to pop up .... my own tools are in-house and any progress bars I would like to add myself. I don't need to wait 5 sec on Application Task when previously it was humming along fine at 30fps.

Can you have this optional by any chance?


(Feels like it happens whenever Unity does GC stuff). I could leave editor alone then come back and turn cam in scene view and boom there it is...

 

If the rate it appears in my use-case is "normal", then I think it should either be a togglable in the options or the threshold be bumped to say... 3-4 seconds? (I feel like 3-4 seconds is the point where I'll start wondering if Unity hang or not, and then the dialogue popping up would be useful).

BUT, I'm not sure whether what I'm seeing is normal or not.

Does 2020.x actually freeze a lot more than what I'm used to from previous versions, or is the dialogue just making it much more apparent?

I think it's the former, but I'm not sure yet. But if that's the case, then the freezes themselves should be the thing to fix.

I don't use a lot of packages, the only extras I add are Quick Search, Collaborate and FBX Exporter. I guess the first two could be suspect.

 

I don't want a popup, just a status icon / text inside the editor.

For example something like the cache server status icon on the bottom right corner, no popups.

Also unity sometimes steals focus when in other apps in mac os, could be related to this popup too?

 

Pretty sure at this point it's tied into GC (my tool makes a ton of garbage as it's editor side only, regens meshes, materials etc)... and it reliably kicks in after 20-25 rebuilds with the slider (scientific I know) - but that's just cos it's made enough garbage for the editor to react and that's when I'm hit with the worst.

So I think it's GC related. I'm gonna poke deeper.

 

I'm fairly sure my tool is just spewing garbage and this popup actually takes focus away from the slider the user is using, so it was completely unnoticeable before, but now really get underfoot and interrupts user control. Happens with Unity's own stuff (URP/Shadergraph) too.

Mouse drag is interrupted by it too, this thing keep stealing mouse focus which is the biggest possible annoyance. Consider you drag with mouse anything, and there is 1 sec delay? Under usual operation there is just a hitch and most of the time you don't notice. Your hardware cursor continues, you still have control on the GUI element and so on.

But with this you lose control, the box pops up, the action from the user is cancelled, it's basically incredibly bad for any project that isn't hyper optimised.

If it's something that can be in preferences and toggled off it will still impact many users, asset store will become a total S*** show in it's present state

 

+deep profiling (or regular profiling) is now popup city too...

 

Yo! Sorry just so busy (sunday and deadline also) but I managed to reduce most of the problem down to a simple call to:

Vector2[] uv = mesh.uv;

That innocent childlike code, full of wonder, really triggered your system, especially if called often. I guess it is Unity clearing up GC Allocs that set it off big time...

So basically anything editor related like shadergraph or anything that makes Unity do GC work seems to be the trigger here.

Will try to provide better repro stuff once I'm out of the trenches my end. Thanks for indirectly optimising my editor code though - got me reducing my allocs a lot

Still got major pausing but fairly sure now any form of GC is the enemy for this new feature.

 

Am I the only one who really digs this change? I love seeing the timer there so I easily get better understanding on how long different tasks take (instead of just estimating them on my head or go through trouble of timing them myself).

It just makes the cost of operations way more transparent IMO and also indicates that editor is busy (in past I used to click around to see when it's responsive again).

I do agree the thing would be way less intrusive though if it was handled in the main editor UI. But for some dialogs it really makes a lot more sense where it is now.. like when building things and doing other tasks when you'd get the popup anyway.

 

I say the editor is busy too often. This dumb progress indicator does not help, but vice versa. Especially in HDRP. Created new material - wait for the shader to compile, move the camera - wait for the shader to compile, press some button - wait for something again. Do not even compare, say with unity 2017, where everything was done for some reason IMMEDIATELY! What a crap!

 

I prefer just showing progress bar at the right bottom of Editor just like how bake lighting does.

 

Answer from Aras:

 

Just wanted to comment that while that UI bar is technically frozen today while processing things, it doesn't mean Unity couldn't make it "special" in a way that it runs on separate thread like the progress bar change if they really wanted to

It just has way bigger impact on everything existing so it feels that putting the popup was just the "easy way" out.

 

I guess not for the bar alone but that is just one thing among others that get blocked right now. For example Package Manager processing blocking the whole interface is an issue, especially since you could at the same time queue other package updates/installs etc while it processes stuff.

Not trying to sound harsh but having UI blocking the whole editor does sound like there's quite a lot of technical debt behind all this and it just keeps going worse the bigger and fancier the engine gets. I do hope Unity keeps spending time to make it better because now it's us users who wait between many operations that shouldn't require waiting from our side.

Also I do know (and appreciate) that there's already been work done in making some things less blocking. Like the new asset import pipeline. So, hoping to see even more things going async in the future.

 

Well I don't mind the extra timing info being shown, it at least just confirms show much time is wasted on waiting...would even prefeer more detailed info on where the hold up is, would make it easier to track down what part of the project or asset is chewing up my time.

 

I am a mixed feelings on this one, part of me likes the recognition of the fact its busy and should tell us it isnt dead but that its struggling and so on, but at the same time, i kinda would have liked it to be a status bar thing too.. we shouldnt be getting hung UI issues, I thought the 1990s were over and the days of locked UIs were over and threading had been embraced. So it feels a bit like fixing the symptom not the problem, where we need fixing of whatevers taking too long or breaking the UI thread, not having a nanny system that pops up to say.. but its better than nothing which we had before.

 

On Mac there is already the spinning beachball to indicate things are stalling, and its less intrusive.

 

People used to use the hourglass thing in windows, but they seem to be going off that

 

I just want it so it defaults to off, because no matter how refined this feature becomes it can't solve the 1.1s flash issue. This will always pop up and eventually grind everyone's gears.

This feature is fantastic perhaps, for Unity developers or asset developers but is actually intrusive for everyday dev.

The editor is filled with micro-pausing from any number of assets from asset store, Unity's own stuff and across a wide range of applications. On a laptop its easy for the os to stutter sometimes and this just throws up tonnes of little hold ons which never were there before and often never noticed cos the user was panning the scene or just pondering settings, but now it's a flashy rave disco dance of popups.

It's just not something I can see defaulting to on.

 

• 2 make it configurable in preferences.

This fixes all my concerns, thanks!

 

I do think this dialog should pop up by default. If it's configurable and people can turn it off manually, that's win-win IMO then.

I spend a lot of time on official unity discord and there's reoccurring theme on especially new users wanting to kill the Unity process when they think it's stuck, on project opening etc. Having a message on screen telling them to wait is probably going to at least help on some of these cases.

 

1second is fine.. or configurable

 

Hopefully asset store authors will have time to remove their own progress boxes or people will be hit by 2 at the same time, unless this feature auto-detects, but that sounds like just confusion waiting to happen.

I'm not making a fuss because I dislike it (I actually do like it) but because I think it's got potential to disrupt way more than it will help if on by default.