Delayed undo in material preview #89127
Labels
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
6 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#89127
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
{F10170224}System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce RTX 2070 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 462.59
Blender Version
Broken: version: 2.93.0, branch: master, commit date: 2021-06-02 11:21, hash:
84da05a8b8Worked: (2.91.2)
Short description of error
I've been using 2.83 for the last year and just upgraded to 2.93, I've found this is also a problem in 2.92. I'm sticking with 2.83, but thought I'd report to see if this can be fixed in 2.93 so I can use it in the future, and I couldn't find any topics that were quite the same.
When in material preview and in object mode there seems to be a short delay in the undo action 1-3 seconds every time I use it. This only seems to be more of a problem when using multiple textures with an alpha and happens to varying degrees depending on complexity of scene and the amount of different materials. This is not a software breaking problem, but can slow down workflow considerably.
The textures I'm using are a little unconventional as I want to use the same textures in unity. I don't know if this makes a difference.
The textures are :
Exact steps for others to reproduce the error
(will likely be a problem with other alpha transparency texture sets.)
*To reproduce the bug load the file in both 2.83 and 2.93 and change into material preview in viewport shading, then duplicate or move one of the cubes, then hit the undo action. In 2.83 it's instantaneous and in 2.93 there is a 1-2 second delay. It's still workable, but a noticeable difference and gets compounded and more noticeable as the scene gets more complex. even with many more objects and textures 2.83 undo is almost instantaneous but 2.93 is up to 5 seconds. I've never seen it above that, and it's something I can work with, but coming from 2.83 it slows down my workflow enough that I'm forced to keep using 2.83. It's minimal enough that if I hadn't just come from 2.83 I would have just thought my scene was too complex.
*Issue only happens in object mode. Edit mode works as expected.
This is reproducible in 2.91.2 and 2.92 as well. 2.91.2 undo is instantaneous and 2.92 there is a short delay. So it seems it's possibly due to some change that happened there.
Added subscriber: @Andrei-Feheregyhazi
Added subscriber: @iss
Changed status from 'Needs Triage' to: 'Needs User Info'
Please pack all textures to .blend file (Click on File > External Data > Pack Resources) and attach file here directly.
Please describe steps to reproduce bug - how can I test, that there is "undo delay".
Uploaded new .blend file and updated the steps to reproduce.
Added subscriber: @Zandman
On my Macbook M1 running Blender 2.93.0 I experience no significant undo delay. I loaded the file, Go into Material Preview. Duplicate some cubes. The Undo is almost instantly.
I've tried testing everything again today and even added considerably more cubes (1500.) When I first tested it, I was able to get 2.83 to have a minimal delay (less than .5 seconds,) and 2.93 had a considerable delay 3-4 seconds. Then I tested about an hour later with even more cubes (3000,) and there was no delay in 2.83 and a minimal delay on 2.93 ( .5 seconds or so.) This leads me to believe it is likely something happening on my system that seems to only be an issue with newer versions, but is intermittent and not consistent so would be difficult to test on other systems. When I have enough downtime to lose my computer for a day, I'll do a full windows reinstall and see if that solves the problem. It's been almost a year since I did that. Also my CPU is older (i7-8700) so that could possibly be a bottleneck.
Just an update on another test. System is again at a 3-4 second delay on 2.93 and no delay on 2.83. So I don't know what's going on. I would assume it was just my system if it didn't work fine in 2.83.
I think I can reproduce the issue, but the delay is nowhere near 3 seconds it's up to 1s with 1K objects, which is still worse than 2.83 though. But this could be a limitation created by bugfix. Will try to bisect to see what caused the regression
3.0 seems to be more swift, but texture drawing seems to be broken, so it's hard to test.
@Andrei-Feheregyhazi did you have any luck with system cleanup?
This is quite strange, but as soon as I started bisecting, I started to notice exact same issue in 2.83 too, and it is much worse than when I first checked this with 2.93. So not quite sure what is going on here.
How did you bisect?
I have number of builds from 2.79 to current master saved. So as I was testing issue on builds from 2.93 to 2.83, after testing about 10 builds I have noticed issue getting progressively worse.
I was able to restore original performance by clearing shader cache in my GPU driver (AMD). Not sure if this is the issue here though.
Edit: This is even stranger than expected, sometimes when I clear shader cache, performance is good and sometimes it is bad. I am quite convinced, that behavior only changes when I clear this cache, but I can't say for 100%
Edit2: I was able to create reliable steps to reproduce, but changing oreder of steps seems to affect performance during runtime so that would suggest, that if shader cache was involved, it would be probably correct behavior.
Added subscriber: @Alaska
Just thought I'd add this here. Sorry, I don't wish to pollute this bug report with random information, but I thought it might help.
Bisecting (in this case) is the process of testing multiple versions of Blender to find the exact commit/change that caused the issue. And in the case of bisecting, you do it in a "bisecting" manner. This is done by picking two versions of Blender. One that you know has the issue and one that you know doesn't have the issue. You then pick a version of Blender halfway between those versions (bisecting) and test if it has the issue. Based on the results you get, you can disregard a large number of versions of Blender to test to find the exact cause for the issue. You repeat this process over and over again until you know the commit/change that caused the issue.
If you have Blender setup so you can compile it from the source code on your computer, then you can bisect a issue with that by using the
git bisectcommand.git bisectwill handle a bit of the work for you.I can walk you through the entire process if you want me too. But it's probably best done somewhere else. Maybe on devtalk if you have an account?
Removed subscriber: @Alaska
Added subscriber: @Alaska
Ah, I thought it was some source code diffing thing.
Thanks! I have been a professional software developer for the last twenty years or so and have been using Git for several years. And never had I heard of the term 'bisecting' in this context, nor that Git has explicit support for this. Of course I have performed to steps to find a "rotten" commit many times. But I didn't know it had a name and didn't know Git supported it. Learned something today :-)
Changed status from 'Needs User Info' to: 'Needs Triage'
Added subscribers: @fclem, @Jeroen-Bakker
I thought I was onto something, but ultimately I am not able to reproduce any significant regression.
Perhaps @fclem or @Jeroen-Bakker could reproduce or have a clue why this can happen.
Added subscriber: @lichtwerk
Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'
will reflect this by setting to "Needs Information from Developers"
(Testing 2.93.3)
Just updating on some hardware related testing I've done on this issue.
So I was finally able to test again on a 2019 MacBook pro 16" to see if there it might be OS related, and the same issue is happened there, so it's not OS related. I also bought an NVLINK for my 2 RTX2070 cards since I saw that 2.93 should be able to share memory between cards with one and I thought maybe it had something to 2 with the 2 cards working separately. Again it didn't make a difference.
On system clean up I noticed the delay is only about 2.5 seconds, which is manageable with single undo's but when strung together it leads to a very long refresh time. The 2.5 seconds is also consistent on the MacBook Pro I tested on.
I've added the file I've been working on that is giving the issues, just in case there are some settings in the project that could be changed/ are causing the issue, though I tend not to change much. I also tested the materials with different blend modes (since originally I had thought it was an issue with alphas, but none of the blend mode settings in the materials seemed to make any difference in the undo delay.
I don't know if any of this helps at all, I just thought I'd share the additional testing I've done.
Undo Delay.blend
Isn't this related to #90593?
It looks that it is, I can no longer reproduce the issue in latest alpha, so will merge reports.
Closed as duplicate of #90593