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

Closed
opened 2021-02-18 02:37:59 +01:00 by CHET · 35 comments

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":

  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.
**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.
Author

Added subscriber: @cheteron

Added subscriber: @cheteron

#89667 was marked as duplicate of this issue

#89667 was marked as duplicate of this issue

Added subscriber: @mano-wii

Added subscriber: @mano-wii

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

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

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.
Member

Added subscriber: @lichtwerk

Added subscriber: @lichtwerk
Member

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.
Author

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)
Author

New scene

QxU9LMzH2i.mp4

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

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

GIF:
GIF.gif

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

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

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

Test please this file

test.blend

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

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

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

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)
Author

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)

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.
Author
[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)

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.
Author

image.png

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

Added subscriber: @ankitm

Added subscriber: @ankitm
Member

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)
Member

Added subscriber: @PratikPB2123

Added subscriber: @PratikPB2123
Member

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 :)

Added subscriber: @Garek

Added subscriber: @Garek

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.
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.
Member

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.

> 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.
Member

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

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

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.

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
Member

Added subscriber: @PMA33

Added subscriber: @PMA33

Added subscriber: @mont29

Added subscriber: @mont29

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.

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...

This issue was referenced by f1173749c2

This issue was referenced by f1173749c2f9c9cb9640ba5b5470dbb28c2494c1

This issue was referenced by ad245a25e2

This issue was referenced by ad245a25e235884ffb756f95e1d82f67f5197bf1

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Bastien Montagne self-assigned this 2022-04-14 16:49:36 +02:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
8 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#85756
No description provided.