Regression: 3.1 & 3.2 Image/UV Editor poor performance (Byte textures, window dragging, maximizing area) #95428

Open
opened 2022-02-02 11:05:31 +01:00 by Jan Kadeřábek · 84 comments

System Information
Operating system: Win 10
Graphics card: 980 Ti, recent drivers

Blender Version
Broken: 3.1 beta v31.f420118335e4 and 3.2 alpha master.95005bbe02cf
Worked: 3.0.x

Short Description
Test 1:
When interacting with UV / Image editor my fps drops from 144 to ~20 - depending on how large is the Image Editor window.
The actual image size or format doesn't affect the performance at all, but Image Editor without any image loaded (just with grid) is completely smooth when moving it around.

Test 2:
The performance is also significantly lower when dragging any window border
Was completely smooth in 3.0.x
Could be specific for this GPU / architecture, since my coworker with AMD can't reproduce the issue.
note this also has its own report, see #97272 (Regression: Blender 3.1 UI editor resize /border dragging performance), so maybe this could be removed from this report...

Steps to Reproduce
Test 1:

open UV / Image Editor
load any image
pan the view around, move UVs etc
should be noticeably slower than in 3.0.x
2022-02-02 11-03-10.mp4

Test 2:
open the default scene
drag any window border
should be noticeably slower than in 3.0.x
2022-02-02 11-00-05.mp4

**System Information** Operating system: Win 10 Graphics card: 980 Ti, recent drivers **Blender Version** Broken: 3.1 beta v31.f420118335e4 and 3.2 alpha master.95005bbe02cf Worked: 3.0.x **Short Description** Test 1: When interacting with UV / Image editor my fps drops from 144 to ~20 - depending on how large is the Image Editor window. The actual image size or format doesn't affect the performance at all, but Image Editor without any image loaded (just with grid) is completely smooth when moving it around. Test 2: The performance is also significantly lower when dragging any window border Was completely smooth in 3.0.x Could be specific for this GPU / architecture, since my coworker with AMD can't reproduce the issue. note this also has its own report, see #97272 (Regression: Blender 3.1 UI editor resize /border dragging performance), so maybe this could be removed from this report... **Steps to Reproduce** Test 1: open UV / Image Editor load any image pan the view around, move UVs etc should be noticeably slower than in 3.0.x [2022-02-02 11-03-10.mp4](https://archive.blender.org/developer/F12841598/2022-02-02_11-03-10.mp4) Test 2: open the default scene drag any window border should be noticeably slower than in 3.0.x [2022-02-02 11-00-05.mp4](https://archive.blender.org/developer/F12841595/2022-02-02_11-00-05.mp4)

Added subscriber: @JanKaderabek

Added subscriber: @JanKaderabek

#97250 was marked as duplicate of this issue

#97250 was marked as duplicate of this issue

#96753 was marked as duplicate of this issue

#96753 was marked as duplicate of this issue

#96659 was marked as duplicate of this issue

#96659 was marked as duplicate of this issue

#96346 was marked as duplicate of this issue

#96346 was marked as duplicate of this issue

#96062 was marked as duplicate of this issue

#96062 was marked as duplicate of this issue

Added subscriber: @Lorenzo-Clerici

Added subscriber: @Lorenzo-Clerici
Jan Kadeřábek changed title from 3.1 & 3.2 Image Editor poor performance compared to 3.0.x (980 Ti) to 3.1 & 3.2 Image Editor & window dragging poor performance (980 Ti) 2022-02-02 11:15:41 +01:00
Member

Added subscriber: @PratikPB2123

Added subscriber: @PratikPB2123
Member

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

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

Hi, thanks for the report. Don't see any drop in fps when I pan in image editor.
Are you able to confirm with factory preferences?: {nav Edit > Preferences > Save & Load (3 horizontal lines) > Load Factory preferences}
image.png

Operating system : Windows-10-10.0.18362-SP0 64 Bits
Graphics card : AMD Radeon(TM) 535 ATI Technologies .```
Hi, thanks for the report. Don't see any drop in fps when I pan in image editor. Are you able to confirm with factory preferences?: {nav Edit > Preferences > Save & Load (3 horizontal lines) > Load Factory preferences} ![image.png](https://archive.blender.org/developer/F12717357/image.png) ```System Information Operating system : Windows-10-10.0.18362-SP0 64 Bits Graphics card : AMD Radeon(TM) 535 ATI Technologies .```

In #95428#1300088, @PratikPB2123 wrote:
Are you able to confirm with factory preferences?

Hi Pratik, yes - I used the clean installation and also loaded the factory default preferences & restarted Blender.

> In #95428#1300088, @PratikPB2123 wrote: > Are you able to confirm with factory preferences? Hi Pratik, yes - I used the clean installation and also loaded the factory default preferences & restarted Blender.
Member

Hi, thanks for the update. I will ask someone to test on Nvidia (I am not sure if it's really GPU specific)
Can you confirm if these steps I need to follow in order to reproduce?-

  • Open default scene
  • Switch to Image editor
  • Add "any" image
  • pan the view with different zoom value
Hi, thanks for the update. I will ask someone to test on Nvidia (I am not sure if it's really GPU specific) Can you confirm if these steps I need to follow in order to reproduce?- - Open default scene - Switch to Image editor - Add "any" image - pan the view with different zoom value

Test 1 (shown in second video):

  • open the default scene
  • drag any window border

should be noticeably slower than in 3.0.x

Test 2 (first video):

  • open UV / Image Editor
  • load any image
  • pan the view around, move UVs etc
  • should be noticeably slower than in 3.0.x

Interaction with a content of any other windows (like 3D Viewport, Video Sequencer, Shader Editor etc.) is completely smooth.

**Test 1** (shown in second video): - open the default scene - drag any window border # should be noticeably slower than in 3.0.x **Test 2** (first video): - open UV / Image Editor - load any image - pan the view around, move UVs etc - should be noticeably slower than in 3.0.x Interaction with a content of any other windows (like 3D Viewport, Video Sequencer, Shader Editor etc.) is completely smooth.

Added subscriber: @Slowwkidd

Added subscriber: @Slowwkidd

I'm no developer, but couldn't this be caused by the recent performance updates of the image editor of last week: https:*developer.blender.org/rBbdd74e1e933, https:*developer.blender.org/rB0a32ac02e97? They are supposed to actually improve performance with large images, but maybe they are messing with something else.

I'm no developer, but couldn't this be caused by the recent performance updates of the image editor of last week: https:*developer.blender.org/rBbdd74e1e933, https:*developer.blender.org/rB0a32ac02e97? They are supposed to actually improve performance with large images, but maybe they are messing with something else.
Member

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

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

Added subscribers: @Jeroen-Bakker, @lichtwerk

Added subscribers: @Jeroen-Bakker, @lichtwerk
Member

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

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

Thx reporting.
I noticed this, too (but did not investigate immediately, [blamed it on my health/vision for the time being :)]
So I can confirm this (it is not super obvious, but the lag still makes you feel uncomfortable doing the Test described).

**System Information**
Operating system: Linux-5.13.0-0.rc6.45.fc35.x86_64-x86_64-with-glibc2.34.9000 64 Bits
Graphics card: NVIDIA GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 495.44
version: 3.2.0 Alpha, branch: master, commit date: 2022-02-02 12:12, hash: `rBe54fba5591a9`

@Jeroen-Bakker: mind checking?

Thx reporting. I noticed this, too (but did not investigate immediately, [blamed it on my health/vision for the time being :)] So I can confirm this (it is not super obvious, but the lag still makes you feel uncomfortable doing the Test described). ``` **System Information** Operating system: Linux-5.13.0-0.rc6.45.fc35.x86_64-x86_64-with-glibc2.34.9000 64 Bits Graphics card: NVIDIA GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 495.44 version: 3.2.0 Alpha, branch: master, commit date: 2022-02-02 12:12, hash: `rBe54fba5591a9` ``` @Jeroen-Bakker: mind checking?
Philipp Oeser changed title from 3.1 & 3.2 Image Editor & window dragging poor performance (980 Ti) to 3.1 & 3.2 Image Editor & window dragging poor performance (nvidia GPUs) 2022-02-02 14:03:07 +01:00

Added subscriber: @slowburn

Added subscriber: @slowburn

I'm also getting severe slowdown in image editor (nvidia gpu as well). It seems that gpu acceleration doesn't work for hi-res images. For example, if I load a small 500x500px image, then gpu utilization is 30-40% and panning is very smooth, but with 4k image gpu usage is only few percent and panning is really slow (2-3fps). Also cpu is getting maxed-out on 1 thread.

I'm also getting severe slowdown in image editor (nvidia gpu as well). It seems that gpu acceleration doesn't work for hi-res images. For example, if I load a small 500x500px image, then gpu utilization is 30-40% and panning is very smooth, but with 4k image gpu usage is only few percent and panning is really slow (2-3fps). Also cpu is getting maxed-out on 1 thread.
Philipp Oeser changed title from 3.1 & 3.2 Image Editor & window dragging poor performance (nvidia GPUs) to Regression: 3.1 & 3.2 Image Editor & window dragging poor performance (nvidia GPUs) 2022-02-18 10:11:27 +01:00

Added subscriber: @Diogo_Valadares

Added subscriber: @Diogo_Valadares

I'm also getting lag in the image editopr but I'm using an AMD card(rx5700xt)

I'm also getting lag in the image editopr but I'm using an AMD card(rx5700xt)

Added subscriber: @rolandmm

Added subscriber: @rolandmm

I created a duplicate (sorry - #95428) can be merged into this one.

I've provided a little blend file that consistently lags.

If the window has no loaded texture it's fine but as soon as I create a texture 4096x4096 and focus it it begins lagging.

I'm using an RTX 2070

I created a duplicate (sorry - #95428) can be merged into this one. I've provided a little blend file that consistently lags. If the window has no loaded texture it's fine but as soon as I create a texture 4096x4096 and focus it it begins lagging. I'm using an RTX 2070

Using a 1024 texture seems to reduce the lag somewhat.

Using a 1024 texture seems to reduce the lag somewhat.

Added subscriber: @SteffenD

Added subscriber: @SteffenD

I was just about to submit a bug report but found this task here.

I can totally confirm the lags, 3.01 is fine, 3.2 master is slow. I found that it's easily reproducible:

  • Open a fresh Blender
  • Pressing F11 to switch to an image editor
  • Add a new image here. The lag is more obvious with larger resolutions that's why I picked a color grid at 8k image.png
  • Pan&zoom the image editor. On my system (Linux, RTX 2070 Super) I get less than 1fps.

Now the funky part:

  • Switch the image to "Float Buffer" here image.png
  • Pan&zoom is much much smoother now. So it seems to affect byte buffers especially?
I was just about to submit a bug report but found this task here. I can totally confirm the lags, 3.01 is fine, 3.2 master is slow. I found that it's easily reproducible: - Open a fresh Blender - Pressing F11 to switch to an image editor - Add a new image here. The lag is more obvious with larger resolutions that's why I picked a color grid at 8k ![image.png](https://archive.blender.org/developer/F12890295/image.png) - Pan&zoom the image editor. On my system (Linux, RTX 2070 Super) I get less than 1fps. Now the funky part: - Switch the image to "Float Buffer" here ![image.png](https://archive.blender.org/developer/F12890304/image.png) - Pan&zoom is much much smoother now. So it seems to affect byte buffers especially?
Jeroen Bakker self-assigned this 2022-02-28 16:38:07 +01:00
Member

I am working on a solution for this.

I am working on a solution for this.
Member

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Member

Fixed by 5e9c1feb8a

Fixed by 5e9c1feb8a

Does the fix suppose to be included in the 3.1 Release Candidate or the latest 3.2 build?
Because I don't notice any difference.

Does the fix suppose to be included in the 3.1 Release Candidate or the latest 3.2 build? Because I don't notice any difference.

3.1 Stable and the issue is still there. Has anybody actually tested it?

3.1 Stable and the issue is still there. Has anybody actually tested it?
Member

Changed status from 'Resolved' to: 'Confirmed'

Changed status from 'Resolved' to: 'Confirmed'
Member

Hm, can confirm this still seems unfixed (the border dragging actually got worse...)

@Jeroen-Bakker: mind checking again?

Hm, can confirm this still seems unfixed (the border dragging actually got worse...) @Jeroen-Bakker: mind checking again?
Member

This a todo. we cache a float variant inside the area. when the area changes its dimension these caches are freed.

This a todo. we cache a float variant inside the area. when the area changes its dimension these caches are freed.
Member

Solution is to move the cache to a global location. (current location: IMAGE_InstanceData#float_buffers

Solution is to move the cache to a global location. (current location: `IMAGE_InstanceData#float_buffers`

The issue isn't present in 4932269ec3.

4096x4096 textures transform and zoom greatly improved.

The issue isn't present in 4932269ec3fa. 4096x4096 textures transform and zoom greatly improved.

Texture size doesn't matter, the UV Editor window size does. Even panning a 128x128 texture is very laggy when UV Editor is maximized (I get around 10fps on 1440p & 980Ti, dragging a window border is now like 2fps.).
I hope this will be fixed, so we get 3.0.1 performance back.

Texture size doesn't matter, the UV Editor window size does. Even panning a 128x128 texture is very laggy when UV Editor is maximized (I get around 10fps on 1440p & 980Ti, dragging a window border is now like 2fps.). I hope this will be fixed, so we get 3.0.1 performance back.

Even maximized I'm not noticing anywhere near the issues panning the window around I was seeing in 7aa0be4b32 with 4932269ec3.

Running an RTX 2080.

Even maximized I'm not noticing anywhere near the issues panning the window around I was seeing in 7aa0be4b32 with 4932269ec3fa. Running an RTX 2080.

In #95428#1319443, @rolandmm wrote:
Even maximized I'm not noticing anywhere near the issues panning the window around I was seeing in 7aa0be4b32 with 4932269ec3.

Running an RTX 2080.

I tested 3.1 Stable, today's build c77597cd0e, and the performance is way worse on my 980Ti than in 3.0.1 (which is perfectly smooth even with 8K images and fullscreen), you just don't find it that bad because of your powerful GPU I guess.
I really hope this will get fixed, so we get exactly the same performance as in 3.0.1. The support for extra large images is cool, but only very small fraction will actually take advantage of it, but having way worse general UV Editor performance on nVidia will complicate life for more than 50% users.
Doing such simple task like UV mapping now becomes irritating, and it would certainly prevent me from upgrading to 3.1.

> In #95428#1319443, @rolandmm wrote: > Even maximized I'm not noticing anywhere near the issues panning the window around I was seeing in 7aa0be4b32 with 4932269ec3fa. > > Running an RTX 2080. I tested 3.1 Stable, today's build c77597cd0e15, and the performance is way worse on my 980Ti than in 3.0.1 (which is perfectly smooth even with 8K images and fullscreen), you just don't find it that bad because of your powerful GPU I guess. I really hope this will get fixed, so we get exactly the same performance as in 3.0.1. The support for extra large images is cool, but only very small fraction will actually take advantage of it, but having way worse general UV Editor performance on nVidia will complicate life for more than 50% users. Doing such simple task like UV mapping now becomes irritating, and it would certainly prevent me from upgrading to 3.1.

How this could make it to the final release?
2022-03-10 16-20-06.mp4

How this could make it to the final release? [2022-03-10 16-20-06.mp4](https://archive.blender.org/developer/F12920009/2022-03-10_16-20-06.mp4)
Member

Added subscribers: @RafaelPasquay-2, @Harley

Added subscribers: @RafaelPasquay-2, @Harley

Added subscriber: @VladimirTurcan

Added subscriber: @VladimirTurcan

Just here to confirm and fallow the issue. Still broken in 3.1 release.

Just here to confirm and fallow the issue. Still broken in 3.1 release.
Jeroen Bakker changed title from Regression: 3.1 & 3.2 Image Editor & window dragging poor performance (nvidia GPUs) to Regression: 3.1 & 3.2 Image Editor & window dragging poor performance (Byte textures) 2022-03-15 14:20:34 +01:00
Member

Added subscriber: @EricD2021

Added subscriber: @EricD2021

Sorry for stupid question, but didn't you consider reverting the support for large images (which causes this, right?), until this performance issue is solved (ideally in some branch or so)?
Because in my opinion the generally laggy editor affects almost everyone, while only very small fraction of users will benefit from the large images support.

Sorry for stupid question, but didn't you consider reverting the support for large images (which causes this, right?), until this performance issue is solved (ideally in some branch or so)? Because in my opinion the generally laggy editor affects almost everyone, while only very small fraction of users will benefit from the large images support.
Member

Added subscribers: @GlancingEYE, @OmarEmaraDev

Added subscribers: @GlancingEYE, @OmarEmaraDev

Hello, just a question will this issue be fixed for blender 3.1.1 when it is out ? The issue is really annoying.

Hello, just a question will this issue be fixed for blender 3.1.1 when it is out ? The issue is really annoying.

Any ETA for a fix? I would love to upgrade from 3.0, but this is just too irritating issue for me - it takes like 3 seconds to maximize Image editor even in the latest 3.2 alpha :(
Thank you to anyone going to fix this.

Any ETA for a fix? I would love to upgrade from 3.0, but this is just too irritating issue for me - it takes like 3 seconds to maximize Image editor even in the latest 3.2 alpha :( Thank you to anyone going to fix this.

I have the same question as above, the issue still exists for the new blender 3.1.2, hoping to have it fixed for 3.2. Thanks!

I have the same question as above, the issue still exists for the new blender 3.1.2, hoping to have it fixed for 3.2. Thanks!
Philipp Oeser changed title from Regression: 3.1 & 3.2 Image Editor & window dragging poor performance (Byte textures) to Regression: 3.1 & 3.2 Image/UV Editor poor performance (Byte textures, window dragging, maximizing area) 2022-04-11 16:28:03 +02:00
Member

Added subscriber: @Rawalanche

Added subscriber: @Rawalanche

I started using 2.83 again because it is buttery smooth. You guys have been progressing blender versions too fast and things are getting ignored. is not good

I started using 2.83 again because it is buttery smooth. You guys have been progressing blender versions too fast and things are getting ignored. is not good

In #95428#1339343, @EricD2021 wrote:
I started using 2.83 again because it is buttery smooth. You guys have been progressing blender versions too fast and things are getting ignored. is not good

You can use 3.0.1 (as I do), as it has been broken since 3.1.

> In #95428#1339343, @EricD2021 wrote: > I started using 2.83 again because it is buttery smooth. You guys have been progressing blender versions too fast and things are getting ignored. is not good You can use 3.0.1 (as I do), as it has been broken since 3.1.
Member

Sorry to hear the feedback, but stuff aren't ignored, there are just not enough people who fix this and they have tons of work on their hands. Other priorities have been given to me. I did work on this topic for several days, but haven't found an solution that would work without having other artifacts. This would need more research on what could be a better solution.

Sorry to hear the feedback, but stuff aren't ignored, there are just not enough people who fix this and they have tons of work on their hands. Other priorities have been given to me. I did work on this topic for several days, but haven't found an solution that would work without having other artifacts. This would need more research on what could be a better solution.
Contributor

In #95428#1339553, @Jeroen-Bakker wrote:
Sorry to hear the feedback, but stuff aren't ignored, there are just not enough people who fix this and they have tons of work on their hands. Other priorities have been given to me. I did work on this topic for several days, but haven't found an solution that would work without having other artifacts. This would need more research on what could be a better solution.

In that case, reverting it to the pre-optimization state would be appropriate. As someone above already said, having poorly performing UV editor in general is way bigger issue than display performance with texture sizes artists rarely use (over 8k). I've been using Blender for about 8 years, 4 years actively, and I can't remember ever seeing such a severe performance regression make it to a final release and remain unfixed for longer than a week. This just can not end up being a matter or shoulder shrug and "sorry, we don't have enough developers to work on it right now".

If it's broken, then at least just revert it to the 3.0 state.

This also breaks a larger overall unwritten rule of Blender that the UI performance is always up to certain standard.

> In #95428#1339553, @Jeroen-Bakker wrote: > Sorry to hear the feedback, but stuff aren't ignored, there are just not enough people who fix this and they have tons of work on their hands. Other priorities have been given to me. I did work on this topic for several days, but haven't found an solution that would work without having other artifacts. This would need more research on what could be a better solution. In that case, reverting it to the pre-optimization state would be appropriate. As someone above already said, having poorly performing UV editor in general is way bigger issue than display performance with texture sizes artists rarely use (over 8k). I've been using Blender for about 8 years, 4 years actively, and I can't remember ever seeing such a severe performance regression make it to a final release and remain unfixed for longer than a week. This just can not end up being a matter or shoulder shrug and "sorry, we don't have enough developers to work on it right now". If it's broken, then at least just revert it to the 3.0 state. This also breaks a larger overall unwritten rule of Blender that the UI performance is always up to certain standard.
Member

Note we have a separate report for the border dragging now, see #97272 (Regression: Blender 3.1 UI editor resize /border dragging performance) and I have bisected that one to be caused by 6738ecb64e.

@Jeroen-Bakker: it might make sense to keep separate reports (since these seem like they dont necessarily have the same causes?)

Note we have a separate report for the border dragging now, see #97272 (Regression: Blender 3.1 UI editor resize /border dragging performance) and I have bisected that one to be caused by 6738ecb64e. @Jeroen-Bakker: it might make sense to keep separate reports (since these seem like they dont necessarily have the same causes?)

Agree that this should be reverted if it can't be fixed, nothing can't justify breaking such essential task as UV editing, especially not a niché feature as >8K support.
BTW what is the purpose of setting priorities to bugs? It has been reported and set to High priority immediately after 3.1 release, now we have 3.1.2 and it still hasn't been fixed, and devs who introduced it are now working on new experimental features instead.
What is behind the decision of not fixing this first, if I can ask?
I have big respect for Blender devs, don't get me wrong, I would just like to understand this.

Agree that this should be reverted if it can't be fixed, nothing can't justify breaking such essential task as UV editing, especially not a niché feature as >8K support. BTW what is the purpose of setting priorities to bugs? It has been reported and set to High priority immediately after 3.1 release, now we have 3.1.2 and it still hasn't been fixed, and devs who introduced it are now working on new experimental features instead. What is behind the decision of not fixing this first, if I can ask? I have big respect for Blender devs, don't get me wrong, I would just like to understand this.

Added subscriber: @triget

Added subscriber: @triget

Added subscriber: @Julian-Szigethy

Added subscriber: @Julian-Szigethy
Member

This issue needs some focused attention, due to other priorities on my desk I am not able to handle it right now (other tasks even have higher prio).
Reverting isn't that easy as a lot of changes were applied using the new system. I do understand the situation we are in and that I am responsible for it.

I believe this will be my top prio in a month. If a developer want to take on this task beforehand, please get in touch with me.

This issue needs some focused attention, due to other priorities on my desk I am not able to handle it right now (other tasks even have higher prio). Reverting isn't that easy as a lot of changes were applied using the new system. I do understand the situation we are in and that I am responsible for it. I believe this will be my top prio in a month. If a developer want to take on this task beforehand, please get in touch with me.
Member

Lowering priority as this should be considered a project, not a bug fix.

Lowering priority as this should be considered a project, not a bug fix.

This issue was referenced by a7417ba845

This issue was referenced by a7417ba84527d57391599d26a1872c035c5e2c48
Member

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Member

Changed status from 'Resolved' to: 'Confirmed'

Changed status from 'Resolved' to: 'Confirmed'
Member

Note that the resizing bottleneck has been solved. Restoring maximise area isn’t possible at this moment.

Will keep this task open and set to known issue.

Note that the resizing bottleneck has been solved. Restoring maximise area isn’t possible at this moment. Will keep this task open and set to known issue.

In #95428#1351888, @Jeroen-Bakker wrote:
Lowering priority as this should be considered a project, not a bug fix.

Fortunately I have recently upgraded my HW, so even though the UV editor performance is nowhere near to 2.79 or 3.0.1, it is somewhat tolerable now.
I just hope that calling it "known issue" doesn't put it next to other known issues not resolved for years.
So thanks in advance for fixing this.

> In #95428#1351888, @Jeroen-Bakker wrote: > Lowering priority as this should be considered a project, not a bug fix. Fortunately I have recently upgraded my HW, so even though the UV editor performance is nowhere near to 2.79 or 3.0.1, it is somewhat tolerable now. I just hope that calling it "known issue" doesn't put it next to other known issues not resolved for years. So thanks in advance for fixing this.
Member

In #95428#1353307, @Jeroen-Bakker wrote:
Note that the resizing bottleneck has been solved.

Which of the reported tests is this referring to? Test 2 / Border Dragging?
In this regard, I dont see a change/improvement by a7417ba845 unfortunately.
I get the same fps dropping as before (and opposed to 3.0.1 where there is no fps dropping)

> In #95428#1353307, @Jeroen-Bakker wrote: > Note that the resizing bottleneck has been solved. Which of the reported tests is this referring to? Test 2 / Border Dragging? In this regard, I dont see a change/improvement by a7417ba845 unfortunately. I get the same fps dropping as before (and opposed to 3.0.1 where there is no fps dropping)
Member

Test 2 should be considered better as described in the task description and shown in the video.

I can imagine that border dragging might not be solved same as minimizing/maximizing. Fixing this in the short term would lead to increase of memory footprint outside the image memory threshold that the user has set in the user preference.

Perhaps we should add test 3+4 to the description to explain that. Or even better those should perhaps be different reports as they require a different solution.

Test 2 should be considered better as described in the task description and shown in the video. I can imagine that border dragging might not be solved same as minimizing/maximizing. Fixing this in the short term would lead to increase of memory footprint outside the image memory threshold that the user has set in the user preference. Perhaps we should add test 3+4 to the description to explain that. Or even better those should perhaps be different reports as they require a different solution.

I get the same fps dropping as before (and opposed to 3.0.1 where there is no fps dropping)

I can confirm. Dragging the separator between an Outliner and a Properties editor is buttery smooth. But between an Outliner and a 3D Viewport it is still very laggy.

> I get the same fps dropping as before (and opposed to 3.0.1 where there is no fps dropping) I can confirm. Dragging the separator between an Outliner and a Properties editor is buttery smooth. But between an Outliner and a 3D Viewport it is still very laggy.
Member

@SteffenD what does the 3d viewport has to do with this issue? This task is about a regression with the uv image editor.

Is there also a regression for the 3d viewport?

@SteffenD what does the 3d viewport has to do with this issue? This task is about a regression with the uv image editor. Is there also a regression for the 3d viewport?

I don't know. In a default layout try dragging the horizontal separator between the Outliner and the Properties up and down and compare it's responsiveness to dragging the vertical separator between e.g. the Outliner and the 3D View left and right.
If you switch the 3D View to e.g. a Shader Editor, everything is smooth again.

I don't know. In a default layout try dragging the horizontal separator between the Outliner and the Properties up and down and compare it's responsiveness to dragging the vertical separator between e.g. the Outliner and the 3D View left and right. If you switch the 3D View to e.g. a Shader Editor, everything is smooth again.
Member

In #95428#1354307, @Jeroen-Bakker wrote:
Test 2 should be considered better as described in the task description and shown in the video.

No improvement here.
Does not matter if I drag a border between a Shader Editor and a 3DViewport -- as shown in the video -- or a UV Editor and a 3DViewport.

> In #95428#1354307, @Jeroen-Bakker wrote: > Test 2 should be considered better as described in the task description and shown in the video. No improvement here. Does not matter if I drag a border between a Shader Editor and a 3DViewport -- as shown in the video -- or a UV Editor and a 3DViewport.
Contributor

In #95428#1354316, @Jeroen-Bakker wrote:
@SteffenD what does the 3d viewport has to do with this issue? This task is about a regression with the uv image editor.

Is there also a regression for the 3d viewport?

Yes, there is a general UI performance regression, which is related:
https://developer.blender.org/T97272

Between these two performance regressions, it's getting really difficult to distinguish the ratio of how much each of them contributes to the final poor UI performance. So it's obvious users are confued.

> In #95428#1354316, @Jeroen-Bakker wrote: > @SteffenD what does the 3d viewport has to do with this issue? This task is about a regression with the uv image editor. > > Is there also a regression for the 3d viewport? Yes, there is a general UI performance regression, which is related: https://developer.blender.org/T97272 Between these two performance regressions, it's getting really difficult to distinguish the ratio of how much each of them contributes to the final poor UI performance. So it's obvious users are confued.
Member

Seems a bit confusing, what is related to #97272 and what is related to this issue? eg if there isn't an improvement, why did I saw a speedup of 100x on my system?

Seems a bit confusing, what is related to #97272 and what is related to this issue? eg if there isn't an improvement, why did I saw a speedup of 100x on my system?
Contributor

In #95428#1354338, @Jeroen-Bakker wrote:
Seems a bit confusing, what is related to #97272 and what is related to this issue? eg if there isn't an improvement, why did I saw a speedup of 100x on my system?

When you move let's say separator between a 3D viewport and UV editor, it's difficult to tell how much of the performance hit is caused by https:*developer.blender.org/T97272 versus by https:*developer.blender.org/T95428 . Users without access to code level profiling tools can not tell.

> In #95428#1354338, @Jeroen-Bakker wrote: > Seems a bit confusing, what is related to #97272 and what is related to this issue? eg if there isn't an improvement, why did I saw a speedup of 100x on my system? When you move let's say separator between a 3D viewport and UV editor, it's difficult to tell how much of the performance hit is caused by https:*developer.blender.org/T97272 versus by https:*developer.blender.org/T95428 . Users without access to code level profiling tools can not tell.
Member

In #95428#1354338, @Jeroen-Bakker wrote:
Seems a bit confusing, what is related to #97272 and what is related to this issue? eg if there isn't an improvement, why did I saw a speedup of 100x on my system?

@Jeroen-Bakker: Is there a way to test the speedup? I mean did you use Test 2 / steps from the second video directly and measure FPS? Or what is this based on?

> In #95428#1354338, @Jeroen-Bakker wrote: > Seems a bit confusing, what is related to #97272 and what is related to this issue? eg if there isn't an improvement, why did I saw a speedup of 100x on my system? @Jeroen-Bakker: Is there a way to test the speedup? I mean did you use `Test 2` / `steps from the second video` directly and measure FPS? Or what is this based on?
https://developer.blender.org/rB439f86ac89bdd649aa9ccfe258c5f80474788449 fixed the lags once and for all :)
Jeroen Bakker removed their assignment 2022-05-18 16:35:29 +02:00

In #95428#1355606, @SteffenD wrote:
https://developer.blender.org/rB439f86ac89bdd649aa9ccfe258c5f80474788449 fixed the lags once and for all :)

Maybe for maximizing the window, but not for laggy panning an image in the UV / Image editor (larger the window, the worse performance).

> In #95428#1355606, @SteffenD wrote: > https://developer.blender.org/rB439f86ac89bdd649aa9ccfe258c5f80474788449 fixed the lags once and for all :) Maybe for maximizing the window, but not for laggy panning an image in the UV / Image editor (larger the window, the worse performance).

Added subscriber: @jakasan2000

Added subscriber: @jakasan2000
Antanas self-assigned this 2022-06-18 18:35:41 +02:00

I totally confirm

I totally confirm

Added subscriber: @Prekek

Added subscriber: @Prekek
Contributor

Added subscriber: @dupoxy

Added subscriber: @dupoxy
Contributor

Hey @jakasan2000 you claimed this task are you working one a fix ? if Yes thank you.

If not please unclaim it .

Hey @jakasan2000 you claimed this task are you working one a fix ? if Yes thank you. If not please unclaim it .
Antanas was unassigned by Pratik Borhade 2022-06-20 04:43:32 +02:00
Philipp Oeser removed the
Interest
EEVEE & Viewport
label 2023-02-09 15:12:55 +01: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
22 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#95428
No description provided.