Viewport Texture Size Limit causes lags when uv editing with textured viewport on the side #90825

New Issue

Mobin · 2021-08-21T12:54:56+02:00

Mobin commented

2021-08-21 12:54:56 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1660 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 471.41

Blender Version
Broken: version: 2.93.4 Release Candidate, branch: master, commit date: 2021-08-18 12:30, hash: 63559a779c
Broken: 2.92
Worked: 2.91

Caused by df0bce3f7d

Short description of error
Very bad performance on uv editing with viewport with textures

Exact steps for others to reproduce the error
this can be reproduced simply but here is a quick one:

get a project (here I tested Fox Splash that you can find blender cloud) very important to use a project as I could not reproduce it on anything simple as a cube
add a UV editing workspace
turn on textures in viewport
try to edit the uvs of the head of the fox
It lags very hard all of blender goes heavy lag
getting rid of viewport or the texture option in viewport solves it but it did not happen on older version of blender (I tested and 2.90 works fine)

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1660 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 471.41 **Blender Version** Broken: version: 2.93.4 Release Candidate, branch: master, commit date: 2021-08-18 12:30, hash: `63559a779c` Broken: 2.92 Worked: 2.91 Caused by df0bce3f7d **Short description of error** Very bad performance on uv editing with viewport with textures **Exact steps for others to reproduce the error** this can be reproduced simply but here is a quick one: 1) get a project (here I tested Fox Splash that you can find blender cloud) very important to use a project as I could not reproduce it on anything simple as a cube 2) add a UV editing workspace ![image.png](https://archive.blender.org/developer/F10300355/image.png) 3) turn on textures in viewport ![image.png](https://archive.blender.org/developer/F10300357/image.png) 4) try to edit the uvs of the head of the fox It lags very hard all of blender goes heavy lag 5) getting rid of viewport or the texture option in viewport solves it but it did not happen on older version of blender (I tested and 2.90 works fine)

Mobin commented

2021-08-21 12:54:56 +02:00

Added subscriber: @Mobin-2

blender-admin commented

2021-08-21 12:54:56 +02:00

#89859 was marked as duplicate of this issue

blender-admin commented

2021-08-21 12:54:56 +02:00

#89853 was marked as duplicate of this issue

Mobin commented

2021-08-21 15:01:38 +02:00

pin pointed it to an option:
If you set texture limit size to anything but off it will cause the massive lag.
also performance is much better in 3.0 but still this option causes performance issues.

pin pointed it to an option: ![image.png](https://archive.blender.org/developer/F10300443/image.png) If you set texture limit size to anything but off it will cause the massive lag. also performance is much better in 3.0 but still this option causes performance issues.

Philipp Oeser commented

2021-09-01 13:10:27 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2021-09-01 13:10:27 +02:00

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

Philipp Oeser commented

2021-09-01 13:10:27 +02:00

Can confirm, will check.

Philipp Oeser changed title from ~~lags when uv editing with textured viewport on the side~~ to Viewport Texture Size Limit causes lags when uv editing with textured viewport on the side

2021-09-01 14:22:29 +02:00

Jeroen Bakker commented

2021-09-01 14:29:15 +02:00

Added subscriber: @Jeroen-Bakker

Jeroen Bakker commented

2021-09-01 14:29:15 +02:00

Yes, known limitation.

An image can have a single GPUTexture. In the image editor the image is always shown by the highest available resolution. In the 3d viewport the texture limit is applied. In this case the user is describing the GPUTexture is created twice per refresh of the screen as the version of the GPUTexture switches.

image_get_gpu_texture implements the switch.
We might consider to store a second GPUTexture for the Limit Resolution setting. But share the GPUTexture when the texture isn't scaled down.

Yes, known limitation. An image can have a single GPUTexture. In the image editor the image is always shown by the highest available resolution. In the 3d viewport the texture limit is applied. In this case the user is describing the GPUTexture is created twice per refresh of the screen as the version of the GPUTexture switches. `image_get_gpu_texture` implements the switch. We might consider to store a second `GPUTexture` for the Limit Resolution setting. But share the GPUTexture when the texture isn't scaled down.

Jeroen Bakker was assigned by Philipp Oeser

2021-09-01 15:02:56 +02:00

Philipp Oeser commented

2021-09-01 15:02:56 +02:00

Added subscriber: @fclem

Philipp Oeser commented

2021-09-01 15:02:57 +02:00

Seems like blender is constantly fighting with texture sizes between Workbench and Image Editor and updates it to the GPU all the time with two different sizes?
Is it this issue?

In D9160 #230084, @Jeroen-Bakker wrote:

In D9160 #229702, @fclem wrote:
I think this might be a problem if the texture is actually used in as a texture in the viewport / render as they would not match the correct limit. Or does the different image user flag ensure different GPU textures?

When rendering in viewport + image editor it switches GPU textures; Basically it has the next paths that lead to a texture switch

Image editor, UV editor => Only use device max resolution as a limit
Workbench/EEVEE => Use device + user pref max resolution as a limit (this is both for final rendering and viewport rendering)
Texture paint (single texture) => Use device + user pref max resolution as a limit (this is both for final rendering and viewport rendering)

When a texture is requested that does not match the previous usage the texture could be switched.

@Jeroen-Bakker : mind checking? (will dare setting it to High prio since this usecase seems quite common?)

Seems like blender is constantly fighting with texture sizes between Workbench and Image Editor and updates it to the GPU all the time with two different sizes? Is it this issue? > In [D9160](https://archive.blender.org/developer/D9160)#230084, @Jeroen-Bakker wrote: >> In [D9160](https://archive.blender.org/developer/D9160)#229702, @fclem wrote: >> I think this might be a problem if the texture is actually used in as a texture in the viewport / render as they would not match the correct limit. Or does the different image user flag ensure different GPU textures? > When rendering in viewport + image editor it switches GPU textures; Basically it has the next paths that lead to a texture switch > > Image editor, UV editor => Only use device max resolution as a limit > Workbench/EEVEE => Use device + user pref max resolution as a limit (this is both for final rendering and viewport rendering) > Texture paint (single texture) => Use device + user pref max resolution as a limit (this is both for final rendering and viewport rendering) > > When a texture is requested that does not match the previous usage the texture could be switched. @Jeroen-Bakker : mind checking? (will dare setting it to High prio since this usecase seems quite common?)

Philipp Oeser commented

2021-09-01 15:15:12 +02:00

@Jeroen-Bakker: we were typing at the same time, sorry.
Will lower prio then and set to Known Limitation (I do think this quite a bad regression though -- even though the commit of course has its upsides as well...)

@Jeroen-Bakker: we were typing at the same time, sorry. Will lower prio then and set to Known Limitation (I do think this quite a bad regression though -- even though the commit of course has its upsides as well...)

Philipp Oeser commented

2021-09-01 15:58:32 +02:00

Added subscriber: @Olliver