Really slow to return to the previous screen layout (after Maximize Area) in complex scenes #78615

New Issue

pistol ioan · 2020-07-04T22:03:53+02:00

pistol ioan commented

2020-07-04 22:03:53 +02:00

System Information:
Operating system: Windows 10
Graphics card: RTX 2080Ti
CPU: Intel i9 9900K

Blender Version:
Broken: 2.83.1, 2.90.0 Alpha, branch: master, commit date: 2020-07-03 23:03, hash: cad98923d0
Worked: 2.82a

Short description of error:
After toggling maximize area, return to the previous screen layout is really slow in Blender 2.83.1 and 2.90 when compared to Blender 2.82a. See the attached video for an example:
https://www.youtube.com/watch?v=TdJuQkYG5Eg

Test results:
2.82a = 0.5 seconds (Still not as fast as maximizing)
2.90 July 08 31bc76ea4e = about 1 second and half to minimize Area
2.83.1 = about 2 seconds and half to minimize Area

Exact steps for others to reproduce the error:

In a complex scene (as the attached file), toggle Maximize Area 2 times in a row (Ctrl Space, Ctrl Space)
Compare the time it takes for the action to occur between 2.82a and these later versions of Blender.

new Diddlys only bones.blend

**System Information:** Operating system: Windows 10 Graphics card: RTX 2080Ti CPU: Intel i9 9900K **Blender Version:** Broken: 2.83.1, 2.90.0 Alpha, branch: master, commit date: 2020-07-03 23:03, hash: `cad98923d0` Worked: 2.82a **Short description of error:** After toggling `maximize area`, return to the previous screen layout is really slow in Blender 2.83.1 and 2.90 when compared to Blender 2.82a. See the attached video for an example: https://www.youtube.com/watch?v=TdJuQkYG5Eg Test results: 2.82a = 0.5 seconds (Still not as fast as maximizing) 2.90 July 08 31bc76ea4e4b = about 1 second and half to minimize Area 2.83.1 = about 2 seconds and half to minimize Area **Exact steps for others to reproduce the error:** - In a complex scene (as the attached file), toggle `Maximize Area` 2 times in a row (Ctrl Space, Ctrl Space) - Compare the time it takes for the action to occur between 2.82a and these later versions of Blender. [new Diddlys only bones.blend](https://archive.blender.org/developer/F8669945/new_Diddlys_only_bones.blend)

pistol ioan commented

2020-07-04 22:03:53 +02:00

Added subscriber: @istoltoto

Alaska commented

2020-07-05 00:53:10 +02:00

Added subscriber: @Alaska

Alaska commented

2020-07-05 00:53:10 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Alaska commented

2020-07-05 00:53:10 +02:00

I'm personally unable to reproduce this issue, are you able to provide a .blend file that you experience issues in so we can better investigate the issue.

pistol ioan commented

2020-07-06 15:01:45 +02:00

I tried to reproduce this problem in in many isolated ways, (mostly because I can't share all the files)

And I find out that this is just because of armatures and bones.

I attach here the only the bones that we used for trains,
And you can test Toggle Maximize Area in 2.82a and then in 2.83.1, and you will see that is a lot slower.

However, is not as slow as in my video example I share before, because there we have a lot more characters, so I think that for each added character will take even more time.

This armature problem not only slow down Toggle Maximize Area but also when you try to delete something will take more time.
https://youtu.be/OJwsFedIrFA

My intuition is pretty sure that have to do with the the attempt to make the undo faster, and was change the way Blender handle viewport.

new Diddlys only bones.blend

I tried to reproduce this problem in in many isolated ways, (mostly because I can't share all the files) And I find out that this is just because of armatures and bones. I attach here the only the bones that we used for trains, And you can test Toggle Maximize Area in 2.82a and then in 2.83.1, and you will see that is a lot slower. However, is not as slow as in my video example I share before, because there we have a lot more characters, so I think that for each added character will take even more time. This armature problem not only slow down Toggle Maximize Area but also when you try to delete something will take more time. https://youtu.be/OJwsFedIrFA My intuition is pretty sure that have to do with the the attempt to make the undo faster, and was change the way Blender handle viewport. [new Diddlys only bones.blend](https://archive.blender.org/developer/F8669945/new_Diddlys_only_bones.blend)

Rafael Pereira Nogueira commented

2020-07-06 20:35:04 +02:00

Added subscriber: @RafaelNogueira

Alaska commented

2020-07-08 12:51:40 +02:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Alaska commented

2020-07-08 12:51:40 +02:00

I can confirm. The issue seems to originate from the dependency graph taking longer to process.

I don't know enough about this or have the right tools to properly debug this so I'll leave this report to be triaged by someone else.

I can confirm. The issue seems to originate from the dependency graph taking longer to process. I don't know enough about this or have the right tools to properly debug this so I'll leave this report to be triaged by someone else.

pistol ioan commented

2020-07-08 17:21:42 +02:00

I hope someone can look at this matter, because we really want to switch on Blender 2.9 when will be released.
Currently we use blender 2.82a, and we really want that motion blur feature for this tv show.

I hope someone can look at this matter, because we really want to switch on Blender 2.9 when will be released. Currently we use blender 2.82a, and we really want that motion blur feature for this tv show.

Germano Cavalcante commented

2020-07-09 14:58:00 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-07-09 14:58:00 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Germano Cavalcante commented

2020-07-09 14:58:00 +02:00

I cannot reproduce this with either blender 2.82, 2.83.1 and the current development version of Blender.

Maximize Area (Ctrl + Spacebar) works instantly here.

Has the problem already been fixed?

Please try the latest daily build: https://builder.blender.org/download/

If the problem persists, please give us more clear instructions on how to reproduce it from scratch.

I cannot reproduce this with either blender 2.82, 2.83.1 and the current development version of Blender. `Maximize Area` (Ctrl + Spacebar) works instantly here. Has the problem already been fixed? Please try the latest daily build: https://builder.blender.org/download/ If the problem persists, please give us more clear instructions on how to reproduce it from scratch.

pistol ioan commented

2020-07-09 16:14:55 +02:00

Thank you for looking into this,

Is actually slow when minimize Area (in Maximize the area is instant always)
I made some tests again with the new Blender build 2.90 31bc76ea4e

Here is the test only with trains (the results are the same only with the bones):
https://www.youtube.com/watch?v=_Of8lzgWrCw

Test results:
2.82a = Almost instant to minimize Area
2.90 July 08 31bc76ea4e = about 1 second and half to minimize Area
2.83.1 = about 2 seconds and half to minimize Area

The results are more stretched in a full scene with more characters:
https://www.youtube.com/watch?v=URyQ3eWSs00

Here is the clear instructions how to reproduce this:

Open the file I have attached before "new Diddlys only bones.blend"
Go to View >Area > Toggle Maximize Area, and then press it again,

Thank you for looking into this, Is actually slow when minimize Area (in Maximize the area is instant always) I made some tests again with the new Blender build 2.90 31bc76ea4e4b Here is the test only with trains (the results are the same only with the bones): https://www.youtube.com/watch?v=_Of8lzgWrCw Test results: 2.82a = Almost instant to minimize Area 2.90 July 08 31bc76ea4e4b = about 1 second and half to minimize Area 2.83.1 = about 2 seconds and half to minimize Area The results are more stretched in a full scene with more characters: https://www.youtube.com/watch?v=URyQ3eWSs00 Here is the clear instructions how to reproduce this: 1. Open the file I have attached before "new Diddlys only bones.blend" 2. Go to View >Area > Toggle Maximize Area, and then press it again, ![image.png](https://archive.blender.org/developer/F8680932/image.png)

Germano Cavalcante commented

2020-07-09 16:45:44 +02:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Germano Cavalcante changed title from ~~Really slow Toggle Maximize Area in complex scenes~~ to Really slow to return to the previous screen layout (after Maximize Area) in complex scenes

2020-07-10 16:27:04 +02:00

Germano Cavalcante commented

2020-07-10 16:36:29 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Germano Cavalcante commented

2020-07-10 16:36:29 +02:00

I can confirm the regression.
It would be interesting to identify which commit resulted in this.
I'm tagging the animation team because a lot of time seems to be spent on evaluating the drivers.
Also tagging the Data, Assets & I/O module since IO is the category that are most using CPU during the test.

I can confirm the regression. It would be interesting to identify which commit resulted in this. I'm tagging the animation team because a lot of time seems to be spent on evaluating the drivers. Also tagging the `Data, Assets & I/O` module since IO is the category that are most using CPU during the test.

Bastien Montagne commented

2020-07-13 14:41:47 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2020-07-13 14:41:47 +02:00

In #78615#976754, @mano-wii wrote:
I can confirm the regression.
It would be interesting to identify which commit resulted in this.
I'm tagging the animation team because a lot of time seems to be spent on evaluating the drivers.
Also tagging the Data, Assets & I/O module since IO is the category that are most using CPU during the test.

@mano-wii please do a proper job if you want to tag modules, your last sentence makes absolutely no sense to me. Also if you think a bisecting would be interesting, just do it yourself, since you can already reproduce the issue... Adding a note like that does not help fixing or investigating the issue at all.

> In #78615#976754, @mano-wii wrote: > I can confirm the regression. > It would be interesting to identify which commit resulted in this. > I'm tagging the animation team because a lot of time seems to be spent on evaluating the drivers. > Also tagging the `Data, Assets & I/O` module since IO is the category that are most using CPU during the test. @mano-wii please do a proper job if you want to tag modules, your last sentence makes absolutely no sense to me. Also if you think a bisecting would be interesting, just do it yourself, since you can already reproduce the issue... Adding a note like that does not help fixing or investigating the issue at all.

Germano Cavalcante commented

2020-07-13 17:44:58 +02:00

In #78615#978082, @mont29 wrote:
@mano-wii please do a proper job if you want to tag modules, your last sentence makes absolutely no sense to me. Also if you think a bisecting would be interesting, just do it yourself, since you can already reproduce the issue... Adding a note like that does not help fixing or investigating the issue at all.

Maybe I misunderstood this graph and the IO description

I avoid bisecting since it takes a long time and it would be better if I had an idea which commits may have brought the problem (which is common for developers working in the area).
But I will bisect.

> In #78615#978082, @mont29 wrote: > @mano-wii please do a proper job if you want to tag modules, your last sentence makes absolutely no sense to me. Also if you think a bisecting would be interesting, just do it yourself, since you can already reproduce the issue... Adding a note like that does not help fixing or investigating the issue at all. Maybe I misunderstood this graph and the [IO description ](https://docs.microsoft.com/en-us/visualstudio/profiling/i-o-time-threads-view?view=vs-2019) ![image.png](https://archive.blender.org/developer/F8691602/image.png) I avoid bisecting since it takes a long time and it would be better if I had an idea which commits may have brought the problem (which is common for developers working in the area). But I will bisect.

Germano Cavalcante commented

2020-07-13 19:49:24 +02:00

Issue introduced by 4c30dc3431
Here the simplified file:
Diddlys_bones_simplified.blend

Issue introduced by 4c30dc3431 Here the simplified file: [Diddlys_bones_simplified.blend](https://archive.blender.org/developer/F8691864/Diddlys_bones_simplified.blend)

Sybren A. Stüvel commented

2020-07-17 12:05:51 +02:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2020-07-17 12:05:51 +02:00

This is probably related to #77277 then.

Sybren A. Stüvel self-assigned this 2020-07-17 16:48:40 +02:00

Sybren A. Stüvel commented

2020-07-21 15:17:16 +02:00

Changed status from 'Confirmed' to: 'Needs User Info'

Sybren A. Stüvel commented

2020-07-21 15:17:16 +02:00

@istoltoto Can you try again with a recent nightly build of Blender? Performance should be better now.

@istoltoto Can you try again with [a recent nightly build of Blender](https://builder.blender.org/)? Performance should be better now.

pistol ioan commented

2020-07-21 19:23:23 +02:00

Hey Sybren,

I made again the tests with 2.9 last build and I got the same results:

new Diddlys only bones: https://www.youtube.com/watch?v=9UXaSBJBQtM
1.5 second with Blender 2.9 last build.
Almost instant with 2.82a

**and full scene test with more characters:**https://www.youtube.com/watch?v=kvoM2c2o--Q
6 seconds with Blender 2.9 last build
2 seconds with 2.82a

Thank you for try help us with this big problem.

Hey Sybren, I made again the tests with 2.9 last build and I got the same results: **new Diddlys only bones:** https://www.youtube.com/watch?v=9UXaSBJBQtM 1.5 second with Blender 2.9 last build. Almost instant with 2.82a **and full scene test with more characters:**https://www.youtube.com/watch?v=kvoM2c2o--Q 6 seconds with Blender 2.9 last build 2 seconds with 2.82a Thank you for try help us with this big problem.

Sybren A. Stüvel commented

2020-07-23 12:30:37 +02:00

My apologies, I mixed up my patches -- D8334 hasn't been merged yet, so it makes sense that the performance hasn't changed.

I dug into the original file you attached (F8669945), and I noted that the object "DEE_Rig" has over 28000 drivers. Many of these drivers are defined multiple times for the same property. To see what I mean, try this code:

from collections import Counter
c = Counter(f'{d.data_path}[{d.array_index}]' for d in D.objects['DEE_Rig'].animation_data.drivers)
for driver, occurrence in c.most_common(5):
    print(f'{driver}: {occurrence}x')

This outputs:

pose.bones["ORG-foot.L"].constraints["Copy Transforms.001"].influence[0]: 524x
pose.bones["MCH-thigh_ik_stretch.L"].constraints["Limit Scale"].influence[0]: 524x
pose.bones["MCH-toe.L"].constraints["Copy Transforms"].influence[0]: 524x
pose.bones["MCH-foot_pole_ik_socket.L"].constraints["Copy Transforms.001"].mute[0]: 521x
pose.bones["MCH-thigh_ik.L"].constraints["IK"].mute[0]: 521x

Blender 2.83 solved a problem that occurred when multiple drivers would write to the same memory address. I can understand why this particular file is hit so hard by this, as thousands of drivers are now inspected to detect such problems.

My apologies, I mixed up my patches -- [D8334](https://archive.blender.org/developer/D8334) hasn't been merged yet, so it makes sense that the performance hasn't changed. I dug into the original file you attached ([F8669945](https://archive.blender.org/developer/F8669945/new_Diddlys_only_bones.blend)), and I noted that the object "DEE_Rig" has over 28000 drivers. Many of these drivers are defined multiple times for the same property. To see what I mean, try this code: ``` from collections import Counter c = Counter(f'{d.data_path}[{d.array_index}]' for d in D.objects['DEE_Rig'].animation_data.drivers) for driver, occurrence in c.most_common(5): print(f'{driver}: {occurrence}x') ``` This outputs: ``` pose.bones["ORG-foot.L"].constraints["Copy Transforms.001"].influence[0]: 524x pose.bones["MCH-thigh_ik_stretch.L"].constraints["Limit Scale"].influence[0]: 524x pose.bones["MCH-toe.L"].constraints["Copy Transforms"].influence[0]: 524x pose.bones["MCH-foot_pole_ik_socket.L"].constraints["Copy Transforms.001"].mute[0]: 521x pose.bones["MCH-thigh_ik.L"].constraints["IK"].mute[0]: 521x ``` Blender 2.83 solved a problem that occurred when multiple drivers would write to the same memory address. I can understand why this particular file is hit so hard by this, as thousands of drivers are now inspected to detect such problems.

pistol ioan commented

2020-07-23 13:47:03 +02:00

I had no idea the rigging is so bad and have so many useless drivers that slow down soo much.
We need to fix this problem for sure in future and make the rigging more lighter. Thank you for pointing out this problem.

But if Blender can also handle this matter as before would be amazing as well.
Looking forward,

I had no idea the rigging is so bad and have so many useless drivers that slow down soo much. We need to fix this problem for sure in future and make the rigging more lighter. Thank you for pointing out this problem. But if Blender can also handle this matter as before would be amazing as well. Looking forward,

Sybren A. Stüvel commented

2020-07-23 14:33:55 +02:00

How did you even create this file? Neither the user interface nor the Python API allow the creation of multiple drivers on the same property.

Sybren A. Stüvel commented

2020-07-23 15:01:50 +02:00

Changed status from 'Needs User Info' to: 'Resolved'

Sybren A. Stüvel closed this issue

2020-07-23 15:01:50 +02:00

Sybren A. Stüvel commented

2020-07-23 15:01:50 +02:00

@istoltoto Please try again with tomorrow's daily build. It should have D8334 in there.

The dependency graph build time (run with blender --debug-depsgraph-time) for F8669945 on my machine:

Blender Version	Depsgraph build time in seconds
2.82	0.245294
2.83	1.434955
2.90 beta without D8334	0.768940
2.90 beta with D8334	0.251650

In other words, things should be back to the original speed.

@istoltoto Please try again with tomorrow's daily build. It should have [D8334](https://archive.blender.org/developer/D8334) in there. The dependency graph build time (run with `blender --debug-depsgraph-time`) for [F8669945](https://archive.blender.org/developer/F8669945/new_Diddlys_only_bones.blend) on my machine: | Blender Version | Depsgraph build time in seconds | | -- | -- | | 2.82 | 0.245294 | 2.83 | 1.434955 | 2.90 beta without [D8334](https://archive.blender.org/developer/D8334) | 0.768940 | 2.90 beta with [D8334](https://archive.blender.org/developer/D8334) | 0.251650 In other words, things should be back to the original speed.

pistol ioan commented

2020-07-25 13:43:21 +02:00

Can confirm is working 100% as before.
Is mind blowing how professional you guys are and how quick you solve this nasty slowdown.
Thanks guys,

Can confirm is working 100% as before. Is mind blowing how professional you guys are and how quick you solve this nasty slowdown. Thanks guys,

Sybren A. Stüvel commented

2020-07-26 11:12:59 +02:00

@istoltoto Thanks for the confirmation :) I'm still wondering how you got multiple drivers that target the same property. This shouldn't be possible in Blender, and the fact that you could still do this might indicate another bug. If I know how to replicate it, I might be able to fix it.

pistol ioan commented

2020-07-27 09:04:45 +02:00

I asked Zoltan Kondoros who was doing the rig, and he told me:

Translation:

"Hello
I saw your notes on your reported bug
But don't think that I created those problems
Those are all the remaining drivers from all previous attempts
It's from bones that don't even exist anymore
Blender should delete them but don't (bug)
Manually try to delete them and they do not disappear (bug)
So what could I do?
I read somewhere about the bug how blender tries to delete orphaned drivers but goes the wrong way
Wrong path
Yes they missed and so it remains
*misfire: Slight_frown:
And if you notice, those bones are named after the rigify model
Once there was an attempt to rigify the trains and the mess was left behind"

End of translation.

So basically he say that he try to delete them but he couldn't and they remain there from past attempts to do the rigging for the trains.
Hope this will help,

![image.png](https://archive.blender.org/developer/F8722633/image.png) I asked Zoltan Kondoros who was doing the rig, and he told me: Translation: "Hello I saw your notes on your reported bug But don't think that I created those problems Those are all the remaining drivers from all previous attempts It's from bones that don't even exist anymore Blender should delete them but don't (bug) Manually try to delete them and they do not disappear (bug) So what could I do? I read somewhere about the bug how blender tries to delete orphaned drivers but goes the wrong way Wrong path Yes they missed and so it remains *misfire : Slight_frown: And if you notice, those bones are named after the rigify model Once there was an attempt to rigify the trains and the mess was left behind" End of translation. So basically he say that he try to delete them but he couldn't and they remain there from past attempts to do the rigging for the trains. Hope this will help,

Sybren A. Stüvel commented

2020-07-28 18:20:28 +02:00

It doesn't help, as it doesn't answer the actual question (how it was possible to add multiple drivers to the same property). Thanks for trying, though.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Really slow to return to the previous screen layout (after Maximize Area) in complex scenes #78615