-
-
Notifications
You must be signed in to change notification settings - Fork 21.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix slow import when window is unfocused #93953
Fix slow import when window is unfocused #93953
Conversation
c77b3bc
to
1efeb7e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't really measure any noticeable difference (though I only tested with 10% of the import), but the code looks fine.
But I wonder why does it even depend on framerate. Is it because of Main::iteration()
call? Maybe there is a way to call it async somehow.
Yes, I think it's because of |
1efeb7e
to
ce7e161
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally, it mostly works as expected.
Reimporting all resources from the MRP linked in #93877 takes 51 seconds with this PR. I used an optimized editor build for testing, just like in my issue.
The progress dialog clearly redraws very quickly (photosensitivity warning):
fast_redraw.mp4
However, it's not quite as fast as with the "optimal" settings listed in #93877, where I get 12 seconds.
If I set V-Sync mode to Disabled in the Editor Settings with this PR, I get 22 seconds. Enabling Update Continuously has no effect on import times.
I wonder if this has to do with V-Sync only being applied on the main window and not the progress window, or vice-versa.
Edit: Even with current master
and optimal settings, I can't get any lower than 22 seconds (matching this PR with V-Sync disabled in the editor settings). Something else may have caused import speeds to regress between 92c8e87 and b97110c – or in fact, between 92c8e87 and 4d984b6, since I didn't rebase your PR when testing it.
Thanks for testing. I'm glad that you are able to get the same performance has the "optional settings". The only thing I see that could have affected the importation is that commit which was suppose to optimize the load/saving of scenes: b83c64f (#93723) I don't known, maybe it reloads all the meshes to load scene groups?!? I could look into it a bit later. |
After testing 4.3.beta2, 4.3.dev2 and 4.2.2, I can't reproduce my time of 12 seconds with any of their official builds (or my self-compiled build of 92c8e87). I'm not sure how I managed to get that time in the first place. If anything, the latest |
That's a good news!!! I'll not investigate further then. Thanks! |
Needs rebase, then it should be good to merge. |
ce7e161
to
ce42d9d
Compare
Rebased done! I retested with the MRP project from the issue. Performance optimization was as expected. |
Thanks! |
Fixes #93877
Effectively, the importation speed was dependent on the
VSync
andUpdate continuously
settings. That was because there is a lot of progress popup update while importing scenes. DisablingVSync
andUpdate continuously
settings while importing files accelerated the importation process on my computer and I got the same speed now when the editor is focused or not. On my computer, it accelerated the importation of the MRP project from 132 sec. to 88 sec. even when focused.At the same time, I made a couple of little tweaks in the progress popups to prevent redrawing at each step progress passing
p_force_redraw
to false tostep
method.There was also a bug in
ProgressDialog
when more then one step was present. If the second task was updated quickly or withp_force_redraw
at true, the first step was never updated if the first task was usingp_force_redraw
at false. That was becauselast_progress_tick
was global and always updated only for the second task. Whentask_step
was called for the first task,last_progress_tick
was always up to date causing it to return and not update the step.