Adjust Last Operation panel is slow (some Undo/Redo happening?) #85756

New Issue

CHET · 2021-02-18T02:37:59+01:00

CHET commented

2021-02-18 02:37:59 +01:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 950M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 398.35

Blender Version
Broken: version: 2.92.0 Alpha, branch: master, commit date: 2021-01-07 22:28, hash: 61f1faac3f

Short description of error
In scenes with visible or invisible objects with modifiers, the options menu freeze

test.blend
Zh4x6aGphy.mp4

Exact steps for others to reproduce the error

test.blend

Windows, 2.92 (can't use 2.93 or higher) can confirm.
For test file in header (the 2MB one), I can't see any problem with 2.92 or 2.90.0. But 2.83.16 I see slowdown.
Test file (the 26MB one) have problem but not easy to catch at first. How I got it to "work":

Open file
Delete visible sphere
Add another UV sphere
Delete it
Add yet another UV sphere
Change anything via last operation menu and see slowdown
For this bug you only need text object with his modifiers. In 2.83.16 you don't need those steps to reproduce, it's always laggy.

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 950M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 398.35 **Blender Version** Broken: version: 2.92.0 Alpha, branch: master, commit date: 2021-01-07 22:28, hash: `61f1faac3f` **Short description of error** In scenes with visible or invisible objects with modifiers, the options menu freeze [test.blend](https://archive.blender.org/developer/F9813965/test.blend) [Zh4x6aGphy.mp4](https://archive.blender.org/developer/F9813910/Zh4x6aGphy.mp4) **Exact steps for others to reproduce the error** [test.blend](https://archive.blender.org/developer/F9815087/test.blend) Windows, 2.92 (can't use 2.93 or higher) can confirm. For test file in header (the 2MB one), I can't see any problem with 2.92 or 2.90.0. But 2.83.16 I see slowdown. Test file (the 26MB one) have problem but not easy to catch at first. How I got it to "work": 1. Open file 2. Delete visible sphere 3. Add another UV sphere 4. Delete it 5. Add yet another UV sphere 6. Change anything via last operation menu and see slowdown For this bug you only need text object with his modifiers. In 2.83.16 you don't need those steps to reproduce, it's always laggy.

CHET commented

2021-02-18 02:37:59 +01:00

Added subscriber: @cheteron

blender-admin commented

2021-02-18 02:37:59 +01:00

#89667 was marked as duplicate of this issue

Germano Cavalcante commented

2021-02-18 15:19:27 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2021-02-18 15:19:27 +01:00

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

Germano Cavalcante commented

2021-02-18 15:19:27 +01:00

I cannot reproduce this with either the latest stable or current development versions of Blender.

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

Go to File → Defaults → Load Factory Settings and then load your file to see if you still can reproduce this issue.

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

I cannot reproduce this with either the latest stable or current development versions of Blender. Please try the latest daily build: https://builder.blender.org/download/ Go to File → Defaults → Load Factory Settings and then load your file to see if you still can reproduce this issue. If the problem persists, please give us more clear instructions on how to reproduce it from scratch.

Philipp Oeser commented

2021-02-18 15:21:56 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2021-02-18 15:21:56 +01:00

Cannot reproduce here

**System Information**
Operating system: Linux-5.10.12-200.fc33.x86_64-x86_64-with-fedora-33-Thirty_Three 64 Bits
Graphics card: GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 455.45.01
version: 2.93.0 Alpha, branch: master, commit date: 2021-02-07 23:21, hash: `rBeb7d9e2a1bba`

I assume you have checked the lastest builds from https://builder.blender.org/download/?
Please try with File → Defaults → Load Factory Settings to see if you still can reproduce this issue.

Cannot reproduce here ``` **System Information** Operating system: Linux-5.10.12-200.fc33.x86_64-x86_64-with-fedora-33-Thirty_Three 64 Bits Graphics card: GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 455.45.01 version: 2.93.0 Alpha, branch: master, commit date: 2021-02-07 23:21, hash: `rBeb7d9e2a1bba` ``` I assume you have checked the lastest builds from https://builder.blender.org/download/? Please try with File → Defaults → Load Factory Settings to see if you still can reproduce this issue.

CHET commented

2021-02-18 16:00:43 +01:00

Download new 2.93 - same problem. Do you open attach file?
In new scene this problem can't reproduce, but in large or in the scene with Remesh modifier freezes begin
Try in this scene create a sphere and change parameters.

test.blend

7vkXWy6LxP.mp4

Download new 2.93 - same problem. Do you open attach file? In new scene this problem can't reproduce, but in large or in the scene with Remesh modifier freezes begin Try in this scene create a sphere and change parameters. [test.blend](https://archive.blender.org/developer/F9814926/test.blend) [7vkXWy6LxP.mp4](https://archive.blender.org/developer/F9814930/7vkXWy6LxP.mp4)

CHET commented

2021-02-18 16:02:04 +01:00

New scene

QxU9LMzH2i.mp4

New scene [QxU9LMzH2i.mp4](https://archive.blender.org/developer/F9814932/QxU9LMzH2i.mp4)

Germano Cavalcante commented

2021-02-18 16:21:18 +01:00

In #85756#1114856, @cheteron wrote:
Do you open attach file?

GIF:

> In #85756#1114856, @cheteron wrote: > Do you open attach file? GIF: ![GIF.gif](https://archive.blender.org/developer/F9814947/GIF.gif)

Philipp Oeser commented

2021-02-18 16:39:17 +01:00

I am seeing the same as @mano-wii (no issues afaict)

CHET commented

2021-02-18 18:07:50 +01:00

Test please this file

test.blend

Test please this file [test.blend](https://archive.blender.org/developer/F9815087/test.blend)

Philipp Oeser commented

2021-02-28 08:44:49 +01:00

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

Germano Cavalcante commented

2021-03-03 17:02:11 +01:00

I can't reproduce the problem with the new file either.
It is possible that an addon is causing this.
Try with the factory settings (File → Defaults → Load Factory Settings)

I can't reproduce the problem with the new file either. It is possible that an addon is causing this. Try with the factory settings (File → Defaults → Load Factory Settings)

CHET commented

2021-03-03 19:07:16 +01:00

In #85756#1123409, @mano-wii wrote:
I can't reproduce the problem with the new file either.
It is possible that an addon is causing this.
Try with the factory settings (File → Defaults → Load Factory Settings)

It's with factory settings!

dEoflv4nau.mp4

> In #85756#1123409, @mano-wii wrote: > I can't reproduce the problem with the new file either. > It is possible that an addon is causing this. > Try with the factory settings (File → Defaults → Load Factory Settings) It's with factory settings! [dEoflv4nau.mp4](https://archive.blender.org/developer/F9862964/dEoflv4nau.mp4)

Germano Cavalcante commented

2021-03-03 19:56:05 +01:00

Try to run blender_debug-gpu.cmd that is included in the download.
Replicate the problem quickly and then close Blender.
After Blender closes, the logs will be in a text file which can be attached here.
Most likely it will contain more information about the error.

Try to run `blender_debug-gpu.cmd` that is included in the download. Replicate the problem quickly and then close Blender. After Blender closes, the logs will be in a text file which can be attached here. Most likely it will contain more information about the error.

CHET commented

2021-03-03 20:01:11 +01:00

blender_debug_output.txt

blender_system_info.txt

[blender_debug_output.txt](https://archive.blender.org/developer/F9863133/blender_debug_output.txt) [blender_system_info.txt](https://archive.blender.org/developer/F9863134/blender_system_info.txt)

Germano Cavalcante commented

2021-03-03 20:25:45 +01:00

It would be good to redo the tests with factory settings.
Some addons interfered with the results.
uvpackmaster2 for example was not un-registered correctly.
DreamUV-master showed some warnings.

It is interesting to note that there is a space between each message of redo_cb: operator redo Add UV Sphere.
The expected would be something like this:

redo_cb: operator redo Add UV Sphere
redo_cb: operator redo Add UV Sphere
redo_cb: operator redo Add UV Sphere
redo_cb: operator redo Add UV Sphere
(...)

Unfortunately I still don't think there is enough to identify the cause of the problem.
Try to run blender_debug_log.cmd, it might show something more informative.

It would be good to redo the tests with factory settings. Some addons interfered with the results. `uvpackmaster2` for example was not un-registered correctly. `DreamUV-master` showed some warnings. It is interesting to note that there is a space between each message of `redo_cb: operator redo Add UV Sphere`. The expected would be something like this: ``` redo_cb: operator redo Add UV Sphere redo_cb: operator redo Add UV Sphere redo_cb: operator redo Add UV Sphere redo_cb: operator redo Add UV Sphere (...) ``` Unfortunately I still don't think there is enough to identify the cause of the problem. Try to run `blender_debug_log.cmd`, it might show something more informative.

CHET commented

2021-03-03 20:29:15 +01:00

![image.png](https://archive.blender.org/developer/F9863224/image.png)

Ankit Meel commented

2021-06-11 18:09:09 +02:00

Added subscriber: @ankitm

Ankit Meel commented

2021-06-11 18:09:09 +02:00

Can't redo on 2.92, 2.93. On 3.0, there's an use after free issue: T85756_asan_report.txt

Can't redo on 2.92, 2.93. On 3.0, there's an use after free issue: [T85756_asan_report.txt](https://archive.blender.org/developer/F10167094/T85756_asan_report.txt)

Pratik Borhade commented

2021-06-25 05:49:41 +02:00

Added subscriber: @PratikPB2123

Pratik Borhade commented

2021-06-25 05:49:41 +02:00

Can not reproduce either.

system-info.txt

@lichtwerk , Better we tag this as Unconfirmed because no one is able to replicate the issue so far :)

Can not reproduce either. [system-info.txt](https://archive.blender.org/developer/F10199971/system-info.txt) @lichtwerk , Better we tag this as Unconfirmed because no one is able to replicate the issue so far :)

Garek commented

2021-06-25 11:06:36 +02:00

Added subscriber: @Garek

Garek commented

2021-06-25 11:06:36 +02:00

Windows, 2.92 (can't use 2.93 or higher) can confirm.
For test file in header, I can't see any problem with 2.92 or 2.90.0. But 2.83.16 I see slowdown.
Test file in comments have problem but not easy to catch at first. How I got it to "work":

Open file
Delete visible sphere
Add another UV sphere
Delete it
Add yet another UV sphere
Change anything via last operation menu and see slowdown
For this bug you only need text object with his modifiers. In 2.83.16 you don't need those steps to reproduce, it's always laggy.

Windows, 2.92 (can't use 2.93 or higher) can confirm. For test file in header, I can't see any problem with 2.92 or 2.90.0. But 2.83.16 I see slowdown. Test file in comments have problem but not easy to catch at first. How I got it to "work": 1. Open file 2. Delete visible sphere 3. Add another UV sphere 4. Delete it 5. Add yet another UV sphere 6. Change anything via last operation menu and see slowdown For this bug you only need text object with his modifiers. In 2.83.16 you don't need those steps to reproduce, it's always laggy.

Philipp Oeser commented

2021-06-25 12:17:41 +02:00

In #85756#1182509, @Garek wrote:
Windows, 2.92 (can't use 2.93 or higher) can confirm.
For test file in header, I can't see any problem with 2.92 or 2.90.0. But 2.83.16 I see slowdown.
Test file in comments have problem but not easy to catch at first. How I got it to "work":

Open file

Delete visible sphere

Add another UV sphere

Delete it

Add yet another UV sphere

Change anything via last operation menu and see slowdown
For this bug you only need text object with his modifiers. In 2.83.16 you don't need those steps to reproduce, it's always laggy.

I can repro with these steps.

> In #85756#1182509, @Garek wrote: > Windows, 2.92 (can't use 2.93 or higher) can confirm. > For test file in header, I can't see any problem with 2.92 or 2.90.0. But 2.83.16 I see slowdown. > Test file in comments have problem but not easy to catch at first. How I got it to "work": > 1. Open file > 2. Delete visible sphere > 3. Add another UV sphere > 4. Delete it > 5. Add yet another UV sphere > 6. Change anything via last operation menu and see slowdown > For this bug you only need text object with his modifiers. In 2.83.16 you don't need those steps to reproduce, it's always laggy. I can repro with these steps.

Philipp Oeser commented

2021-06-25 12:23:47 +02:00

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

Philipp Oeser commented

2021-06-25 12:28:46 +02:00

Though not really doing anything outside the Adjust Last operation panel in between, #78171 (Adjust Last Operation: Other changes outside that panel are reverted back automatically) might be related in a way.

Philipp Oeser changed title from ~~Freeze option menu~~ to Adjust Last Operation panel is slow (some Undo/Redo happening?)

2021-06-25 14:08:21 +02:00

Philipp Oeser commented

2021-07-22 17:40:40 +02:00

Added subscriber: @PMA33

Bastien Montagne commented

2022-04-14 12:16:20 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2022-04-14 12:16:20 +02:00

Slow down comes from re-evaluation of some heavy Decimate modifier in unrelated objects...

While at step 3 (first adding of new UVSphere) the METext meshes are just re-used as-is during undo/redo, after the second addition of another UVSphere they are re-read in-place, which forces the depsgraph to re-evaluate them (including their very expensive Decimate modifier).

T85756_depgraph_logs.txt

T85756_undo_logs.txt

Still investigating about why those meshes are detected as changed in the latest case.

Slow down comes from re-evaluation of some heavy Decimate modifier in unrelated objects... While at step 3 (first adding of new UVSphere) the `METext` meshes are just re-used as-is during undo/redo, after the second addition of another UVSphere they are re-read in-place, which forces the depsgraph to re-evaluate them (including their very expensive Decimate modifier). [T85756_depgraph_logs.txt](https://archive.blender.org/developer/F13001213/T85756_depgraph_logs.txt) [T85756_undo_logs.txt](https://archive.blender.org/developer/F13001214/T85756_undo_logs.txt) Still investigating about why those meshes are detected as changed in the latest case.

Bastien Montagne commented

2022-04-14 16:36:46 +02:00

This is actually a beautiful bug hidden deep inside the memfile undo step writing code... Took me a while to fully understand the issue. Fix incoming.

In a nutshell, the issue is reproducible when a new ID is added, which is smaller in memory than the one following it. Then is would cause said following ID to be falsely identified as changed (because the initial memory reference_current_chunk for the following ID would not be the first one in the existing, previously written undo step), leading to it being fully re-read and re-evaluated on undo.

In that file, the first added UVSphere creates a MESphere.002 ID that comes before existing MESphere.002 one, which is fine (MESphere.002 being small enough to not trigger the issue). However, second addition of UVSphere creates MESphere.004, which comes before METext, a much, much bigger mesh.

Since MESphere.004 is new, there is no matching existing memchunk, but we still keep iterating over the list of existing memchunk while writing new ones for the new mesh, which lives us 'somewhere' inside of memchunks for METext when we start writing this one. Existing code would then wrongly assume current reference memchunk is good, when we actually want to start writing an ID on the very first reference memchunk matching it, not somewhere in the middle...

This is actually a beautiful bug hidden deep inside the memfile undo step writing code... Took me a while to fully understand the issue. Fix incoming. In a nutshell, the issue is reproducible when a new ID is added, which is smaller in memory than the one following it. Then is would cause said following ID to be falsely identified as changed (because the initial memory `reference_current_chunk` for the following ID would not be the first one in the existing, previously written undo step), leading to it being fully re-read and re-evaluated on undo. In that file, the first added UVSphere creates a `MESphere.002` ID that comes before existing `MESphere.002` one, which is fine (`MESphere.002` being small enough to not trigger the issue). However, second addition of UVSphere creates `MESphere.004`, which comes before `METext`, a much, much bigger mesh. Since `MESphere.004` is new, there is no matching existing memchunk, but we still keep iterating over the list of existing memchunk while writing new ones for the new mesh, which lives us 'somewhere' inside of memchunks for `METext` when we start writing this one. Existing code would then wrongly assume current reference memchunk is good, when we actually want to start writing an ID on the very first reference memchunk matching it, not somewhere in the middle...

blender-admin commented

2022-04-14 16:41:02 +02:00

This issue was referenced by f1173749c2

This issue was referenced by f1173749c2f9c9cb9640ba5b5470dbb28c2494c1

blender-admin commented

2022-04-14 16:41:02 +02:00

This issue was referenced by ad245a25e2

This issue was referenced by ad245a25e235884ffb756f95e1d82f67f5197bf1

Bastien Montagne commented

2022-04-14 16:49:36 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Bastien Montagne closed this issue