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

2020.1.0a24, the "it only appears after 1 second" part is working.

Empty project, 3D template:
• 3 seconds to enter play mode with domain reload, instant exit;
• Instant enter play mode without domain reload, instant exit;
• Instant open default scene;
• 3 seconds to compile;
Pretty standard for Unity.

Project with 1000 assets, about 600 of which are scripts, about 500 of which are from NoesisGUI in a Plugins folder, and about 90 of which are from another asset:
• 43 seconds to compile when reimporting an assembly definition. To be fair, this isn't a common operation;
• 11 seconds to compile when reimporting a script.

Empty scene:
• 5.5 seconds to enter play mode with domain reload, effectively instant exit;
• Effectively instant enter play mode with domain reload, same time to exit;
• Instant open.

Scene with about 10 objects and an entity subscene with 1:
• 7 seconds to enter play mode with domain reload, <0.5 seconds to exit;
• Instant enter play mode without domain reload, same time to exit;
EDIT: Whoops, inverted the times above.
• Instant open.
[whydoestheforumnothavestrikethroughsdammit]By the way, if you're having insane enter play mode times without domain reload, plus a duplicated game window, it might be UIElements Runtime, I ran into it while writing this post. This warning is mostly why I didn't throw this post away.[/whydoestheforumnothavestrikethroughsdammit] Never mind, it was all caused by NoesisGUI.

<sarcasm>Most suboptimal, but still rather standard. It's Unity we're talking about, I don't understand those slowdowns you guys are talking about.</sarcasm>

 

They might make everything feel slower since now it's easier to benchmark this type of stuff, but I can't see how they would slow anything down: they're supposed to be updating themselves with progress that simply gets posted by the operation on the main thread.

I don't really feel like hunting down and installing the version before the progress bars and doing all the benchmarks again. That whole post was motivated by insane slowdowns that ended up being caused by NoesisGUI.

 

Maybe use a different mechanism instead of a full blown focus stealing pop-up? You can set up windows in ways that are less intrusive, like having no default OS chrome and auto positioning to the bottom right corner so it looks less conspicuous.

 

Yes exactly this. When I originally started using Unity a few years back I was surprised at the general editor UI lock-ups, although they weren't that bad back then.

It's bad UX for UI to freeze. Feels like it could be so much better...

I appreciate that you just happen to be the person working on this specific feature and replying to this thread and for what it's worth I think it's good that you are communicating here directly about this specific issue.

I just wanted to say +1 for encouraging Unity editor team to remove whatever super impossible, mountain to climb, tech debt is in the editor so that it isn't such a blocking & freezing user experience.

Maybe take a more long term approach so you can build on more stable foundations.

 

Well, on the Splash Screen they could just update the Splash to something that pulses gently so if it freezes you'll see (would this be any easier to do on a seperate thread? using a visual representation rather than an actual prompt?)

During the editor I agree, It shouldn't niggle me because it's a practical feature and should remain, perhaps moving the prompt to the same bar as the "Compiling Shader" progress bar would be possible? that way we can still see the timer running but it's not in your face unless you actively seek it out.

 

Well they do have a status bar, only it really doesn't get used as much as I would like it to, ie toolbar icons, menus, , progress bars etc customization on it.... hopefully more is done on the general editor gui/ux because it is seriously lacking actual improvements and I haven't noticed any (ie good changes, thefrontend 2019.3 changes are big setback, though the change to the ui backend might be an improvement) in the time I've been using unity, bar the third party assets that do actually try to improve things.

 

That popup is really bad on latest beta. When trying to set Particle System properties (color gradients alpha values etc..) it constantly flashes for a sec when playing with those slider values. Those sliders are now completely unusable. What's going on?

 

My participation in that sweet thread which I already post in the 2020.1 beta thread anyway.

Spent the last 3h on that beta, and this loading popup isn't getting worse since a21? a22?
The waiting time is horrible and I hit the 30s each time I reload script and then again pressing play.
It's really turning out to be a mad thing, and that "AssetDataBase.Refresh" means nothing. You should have wrote "Going KFC, forgotten my keys.".

https://forum.unity.com/threads/unity-2020-1-0-beta-1-has-been-released.845161/#post-5580460

 

But still we could access the editor.
Now it just take over click and we cannot do anything.
"ok let just freeze the editor while its reloading scripts, who care".

 

Pretty sure editor was frozen all along for the processing, or you have a case where it wasn't?

 

I hope Unity use the version of this internally which triggers at 0.5s....

 

I believe Visual Studio is using the same or similar approach as well.

 

It's nice, now to have a metric when filing a bug.
Give it to Aras to add transparency to Unity!

 

You joke but this is actually a great idea and I think I might do that in internal projects (even if the progress bar isn't in release builds) just so I can bring slow points to my attention.

 

It already forced my hand to optimise my own editor tools. It's intolerable nagging would only be made better with a small icon of a happy guy in a rainbow wig. It's a pretty good feature (especially if we can set the parameters).

 

It would be better if the popup text would have at least some kind of meaning, unlike this:



Here the package manager is searching the unity database for a search term. However the popup shows it's repainting the scene ...

 

after simple code change ever, long long time ( Refresh.AssetDatabase, and then Application.Reload ) for wft 20 lines of code, unusable unity version .... and with the xbox live plugin more problems als windows self have bugs *G

 

Got a quick bug report? if you have one just drop the case number here, see if it can be fixed for you. People often register surprise when something comes out of beta but their bug still exists, because they assumed it was common

 

Since I already have that from another bug report, I repost it to visualize the major annoyance. I don't see it as a win, rather a big loss because all the time I wonder what it's actually doing and why can't this perform better, especially why does it take so long to repaint the scene when it actually should load the packages and i'm not in any scene:


Besides I can't do anything anyway while that runs and why does it not have a cancel button in case of e. g. a slow connection?

 

It can't have a cancel button because it's telling you that a thread-blocking operation is ongoing. You can't interact with the program whatsoever; the message box it just to inform you why. I agree that it's not the most elegant or convenient solution, but let's not attack the feature, instead let's focus on the problem it brings to the spotlight.

Getting mad at this is like being Ill and not attacking the virus or even the fever, but instead yelling at the thermometer because it's showing a bad number.

 

If it's blocking and I can't cancel it, the time information and what it's doing is useless. The only information that's required is whether Unity is still alive or if I should kill it in the task manager.

It's custom to allow cancelling long running operations simply because there is no guarantee it will ever end. Best example is the search above. If it takes a minute and I want it to stop because I'm tired of waiting because of e. g. a slow connection, then I should be able to. If it's an operation that must complete, then I shouldn't be able to cancel.

 

I'm guessing that "repaint all scenes" is just above "find packages" in the call stack, so the bug is that the Hold On popup is looking at the wrong call. @Aras, that's probably a real bug to look into, though I imagine diagnosing "what is Unity waiting for" is hard. What are you using to populate the name for the process we're waiting for?

You're correct, but this is a bug in the Package Manager. You should post the complaints about that process being slow and not cancellable here.

 

in the older versions,
when scripts were compiling it was possible to work with editor,
with progress bar, you cannot..? or is it from something else.

 

You could never work while the scripts were compiling during the assembly reload stage of compilation (when the compilation spinner was hanging). Are you seeing the hold on window pop up immediately after you tab over from the code editor?

Is the "Editor Performance Markers" just calls to Profiler.BeginSample?

In that case, we could leverage it for our own tools to just put those in and have the dialogue pop up. We do use EditorUtility.DisplayProgressBar quite a bit, but sometimes the fill amount there is meaningless, so we could just as well piggyback on this feature.

 

Wouldn't a sticky note be better where everyone posts their findings? Otherwise you'd get flooded with bug reports.

 

2017.x
- modify script in vs, alt tab back to unity
- recompiling icon spinning at bottom
- editor is responsive, can rotate camera or select things (well maybe small hang at the end, i guess that's the reload part)

2020.x
- modify script in vs, alt tab back to unity
- recompiling icon spinning at bottom
- editor is not responsive, mouse cursor spinning, progress bar blocks everything else

 

Oh, right, that's a different thing. You can read about it here. It was introduced in Unity 2019, so it's definitely not got anything to do with this loading bar.

Essentially Unity broke that workflow because it wasn't a feature, but an implementation side-effect. I don't know what the status of "fixing" it again is.

@Aras, your team is doing a lot of wonderful work right now on Editor usability (thanks!). Is the issue in that thread something you can at least check in on? It's making me kinda dread working in any version over 2018 because it's so bad.

 

We can live with slow during alpha, then you can take it out on beta or RC.

 

I had this when I created a new project:



It was busy in "Done" ...

I suggest someone at Unity first uses Unity and writes down everything before anyone of the beta users writes a bug. It's just a waste of everyone's time if the trivial and obvious things aren't fixed first

 

But its flaw has become obvious now

 

I agree, before some of the delays didnt entirely show, but now theres a big claxon of an event happening each time and rather than distracting us from it, its making us all stare at it

 

Thanks, of course, but this terrible feature shouldn't have existed at all. Or appear somewhere below, as before. if it's not broke, don't fix it. I can already see that the editor has become slower. My gratitude to this wonderful progress bar that constantly reminds me about it[Sarcasm].

 

Seems like very good changes. I don't mind if editor is unresponsive for sec or two when compiling or whatever, but that popping window was annoying. Now that I can set it to something like 10 secs is very nice.

Overall 2020.1.b2 seems to be quite stable and I haven't experienced any crashes. Also editor feels bit faster than 2019.3. Something has also happened with Android il2cpp builds, as they are now super fast after first build compared to 2019.2

 

Cheers. I actually probably will be setting it to 0.5s at times and maybe 1-3s at other times. It can help narrow down perf issues you didn't know existed.

Seems like it'll be perfect now. Thanks!

 

In 2020.1.0b2 on Windows 10, if I hold the left-mouse button on any of the Minimize/Maximize/Close buttons in the window title-bar, the "Hold on" dialog appears.

PS: Can you replace "Hold on" with "Please wait"?

 

Would be amusing if we could define that in prefs too...

 

thanks for not limiting the max amount to some small value!

 

"computer sez wait!"

 

I am immature enough to write a script on startup that would change the Hold on text to a random one each time to keep things fresh... so please add the text field to prefs too!

 

you'd make lotsa money with this, but not on the asset store anymore because someone had an aneurysm at HQ

 

So I have this project im working on, everytime I enter playmode that "Hold On (busy for...)" pops up. After about a second or two playmode starts. But then when I use the Instantiate() method it pops up again, this time it doesn't go away. I need help, please someone?