Page MenuHome

Render result drawing performance in Image Editor is extremely poor compared to image texture drawing performance.
Closed, ResolvedPublicKNOWN ISSUE

Description

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 451.67

Blender Version
Broken: version: 2.83.2, branch: master (modified), commit date: 2020-07-09 05:50, hash: rB239fbf7d936f
Worked: (newest version of Blender that worked as expected)

Short description of error
When displaying Render Result in Image Editor, the panning and zooming performance is extremely bad (about 5-10FPS), and worsens the more user zooms out, so that paradoxically the less pixels of the texture are drawn in the Image Editor space, the worse the performance is. When the identical rendered image is saved and then loaded back as an image texture, and displayed in the very same Image Editor, the performance is perfect (120+FPS).

Here is video of the issue:
https://youtu.be/nz94eN93Suc

Exact steps for others to reproduce the error

  1. Render at least 2048 * 2048 image
  2. Open Image Editor and set displayed image to "Render Result"
  3. Zoom out a bit and pan around, notice the terrible performance
  4. Save the image from the Image Editor as a file
  5. Load the saved image as an Image Texture
  6. Display the loaded image in the same Image Editor

Result: There is huge performance difference in drawing of the identical data in Image Editor, depending on if it's displayed as Image Texture or Render Result
Expected: There is no performance difference between drawing Render Results and Image Textures

Event Timeline

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.

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.

Philipp Oeser (lichtwerk) reopened this task as Needs Triage.Aug 5 2020, 10:03 AM

Needs another look

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

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

Sergey Sharybin (sergey) changed the subtype of this task from "Report" to "Known Issue".Aug 6 2020, 11:35 AM

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

Germano Cavalcante (mano-wii) changed the task status from Needs Triage to Confirmed.Aug 7 2020, 3:52 AM

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.

Jeroen Bakker (jbakker) closed this task as Resolved.Sep 11 2020, 12:02 PM
Jeroen Bakker (jbakker) claimed this task.