The image editing drawing is currently under developement T67530. If everything goes via plan it will be part of 2.91

Please note that the attached video is private. It is better to upload the mp4 file with the ticket.

In T79518#990438, @Jeroen Bakker (jbakker) wrote:

The image editing drawing is currently under developement T67530. If everything goes via plan it will be part of 2.91

Please note that the attached video is private. It is better to upload the mp4 file with the ticket.

Sorry, that must have been a misclick. It's unlisted now. I am happy that it's in progress, but does it cover this issue? This does not seem like a performance issue that was not solved yet, as image textures perform well. This seems more like a matter of Render Result specifically using perhaps some legacy code for drawing.

@Richard Antalik (ISS)
You've just merged two completely different bug reports!

That one is about poor performance when displaying very high resolution images in Image Editor (which is somewhat expected), while this one is about tremendous difference between displaying two images of identical resolution depending on if they are displayed as Image Texture or Render Result.

It's very concerning how little time you actually spent looking into the issue, for someone who is tasked with triaging issues.

Result: There is huge performance difference in drawing of the identical data [emphasis added] in Image Editor, depending on if it's displayed as Image Texture or Render Result.

I don't think you are comparing identical data in your video. I think you saved the render out as an 8bit png, which will be loaded into an 8bit buffer. The render image buffer is 32bits.

Find steps to redo the bug consistently, and include a small and simple .blend file to demonstrate the bug.

There is a reason why this step is important. If you would have included a .blend file and an image file to test, I wouldn't have to be asking you to confirm this now. 😉 Could you please?

If you save the image in a 16bit or 32bit format and load it back into Blender, I experience the same lag as I do with the render image, which is stored in a 32bit frame buffer.

Here are two screen shot that better duplicate the number of areas in your video.

~10fps with a 16bit png

25 fps with an 8bit png

So more accurately, I would say that this is a drawing performance issue between 8-bit buffers verses half and full float.

I rendered the default scene with a resolution of 2048x2048 but I could not reproduce the problem.
Perhaps this is an issue on NVidia GPUs.
As we are not comparing identical data, this in fact seems to be the same problem as described in T77812

A test file would be good to compare in different setups and the information added in the other report.

Operating system: Windows-10-10.0.18941 64 Bits
Graphics card: Radeon (TM) RX 480 Graphics ATI Technologies Inc. 4.5.13596 Core Profile Context 20.10.19.02 27.20.1019.2002

In T79518#990988, @Ludvik Koutny (rawalanche) wrote:

@Richard Antalik (ISS)
You've just merged two completely different bug reports!

That one is about poor performance when displaying very high resolution images in Image Editor (which is somewhat expected), while this one is about tremendous difference between displaying two images of identical resolution depending on if they are displayed as Image Texture or Render Result.

It's very concerning how little time you actually spent looking into the issue, for someone who is tasked with triaging issues.

Render result is float RGBA+Z image. It is 5 times larger at same resolution. Performance loss will probably depend on HW configuration so my results may differ from yours quite a bit. That is why I assumed this is same issue as in T77812

And as @Jeroen Bakker (jbakker) said image editor is being "rewritten", so I decided that it is safe to just assume. This issue will be probably resolved regardless if my assumption was correct or not.

I could profile this just to be 100% sure, but I can not reproduce such big difference as you or @Evan Wilson (EAW)

This is in fact caused by the same root cause as the T77812.

Blender will not store full image on the GPU as it is too memory inefficient and will make it so user runs out of VRAM very quickly. What Blender does instead is to push tiles of image to the GPU, and it does it on every redraw. This solves memory usage problems but introduces problem of data transfer. There is limited amount of gigabytes per second you can push from CPU memory to the video card, and it's based on size of data, not data resolution.

What happens in T77812 is that it is a 8bit image at a resolution of 10K by 10K. When image editor is zoomed out the entire image is to be pushed to GPU, and it is 10k * 10k * 4 bytes. This is quite substantial amount of data to be transferred, hence the lag.

Ok, now lets see what happens in this report.
The render result is always 32bit float, so it is 2048 * 2048 * 4 * 4 (2K by 2k image, RGBA, 4 bytes per channel). Again, quite substantial amount of data to be transferred.
What happens when render result is saved as PNG? Depending on a settings it will either be 8 or 16 bits per channel, which makes it 2 to 4 times less memory than the 32bit float. This reduces the amount of data which needs to be transferred to GPU on every redraw, it is way less than in the T77812 and hence there is no lag compared to the other report, and no lag compared to the render result.

Thanks for the report, but this is a known issue which has been reported already. There is no easy way to solve it in a way which will work on all setups, and hence this is something what takes a long time to solve.

Addition: I forgot to mention the color management involved into the equation, duh!

The statement of 32bit images transferred to the GPU on every redraw is valid when GLSL is used for color management. It is used in the following cases:

• The User Preferences -> Viewport -> Textures -> Image Display Method is set to GLSL.
• The automatic heuristic detected that image can be transferred to GPU fast enough.

Currently the automatic check will use GLSL if the image is bigger than 2048 by 2048 4 channels 32bit image (which is coincidentally the exact size you used in this report),

Depending on a GPU the current threshold might be a bit too high, so probably we should lower it.

At the meantime a workaround on your side would be to set Preferences -> Viewport -> Textures -> Image Display Method to 2D texture.

P.S. When GLSL is NOT used for color management, the 32bit float buffer is color managed on a CPU and the result of the color management is 8bit per channel image. So, the color management is slow, but it only happens once, and then on a redraw a smaller image is to be pushed to the GPU. Hope it makes sense :)

In T79518#991828, @Sergey Sharybin (sergey) wrote:

Addition: I forgot to mention the color management involved into the equation, duh!

The statement of 32bit images transferred to the GPU on every redraw is valid when GLSL is used for color management. It is used in the following cases:

• The User Preferences -> Viewport -> Textures -> Image Display Method is set to GLSL.
• The automatic heuristic detected that image can be transferred to GPU fast enough.

Currently the automatic check will use GLSL if the image is bigger than 2048 by 2048 4 channels 32bit image (which is coincidentally the exact size you used in this report),

Depending on a GPU the current threshold might be a bit too high, so probably we should lower it.

At the meantime a workaround on your side would be to set Preferences -> Viewport -> Textures -> Image Display Method to 2D texture.

P.S. When GLSL is NOT used for color management, the 32bit float buffer is color managed on a CPU and the result of the color management is 8bit per channel image. So, the color management is slow, but it only happens once, and then on a redraw a smaller image is to be pushed to the GPU. Hope it makes sense :)

I just tried setting the Image Display Method to 2D texture, and indeed, the image display becomes super fast. However I highly doubt something like this should ever be exposed as user preference. It requires such a deep understanding of inner workings of Blender that there's pretty much close to 0 chance anyone adjusting this setting will know what they are doing (unless they look specifically for it based on obscure piece of information they've found randomly on some Blender forum or tracker :) ). This should be solved better, so that the performance issues can be avoided altogether without a need to toggle an obscure knob. Isn't it possible to simply query basic GPU data such as rough performance and amount of available VRAM, and set the setting automatically based on that? Since there's already some sort of "Automatic" option, it just seems that the heuristic employed to decide the right default setting could use some more work.

Furthermore, this issue seems to have much larger impact than I originally though. For example as long as the conditions for this issue to occur are met (Image Display Method is GLSL and the image editor is open anywhere in the UI), then any Blender's floating window moves at the equally poor framerate, so moving any floating windows around is very laggy too, regardless if they display Image Editor, or any other editor.

We fully agree that such things should just work for users. But, unfortunately, this apparently not as trivial to do as it might sound. This is why this issue is still not addressed.

This issue has been addressed by D8234. Please report any new issues as new reports.

D8234 does color transfer on the GPU and uses a cached GPUTexture for drawing, depending on the actual GPU load these textures don't need to be transferred to the GPU every redraw. This can be further improved in the future even more by generating smaller textures. But for now this issue has been solved.