Render result drawing performance in Image Editor is extremely poor compared to image texture drawing performance. #79518

New Issue

Ludvik Koutny · 2020-08-04T16:11:17+02:00

Ludvik Koutny commented

2020-08-04 16:11:17 +02:00

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: 239fbf7d93
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
Blender 2.83 Render Result vs Image performance in Image Editor (720p_30fps_H264-128kbit_AAC).mp4

Exact steps for others to reproduce the error

Render at least 2048 * 2048 image
Open Image Editor and set displayed image to "Render Result"
Zoom out a bit and pan around, notice the terrible performance
Save the image from the Image Editor as a file
Load the saved image as an Image Texture
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

**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: `239fbf7d93` 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 [Blender 2.83 Render Result vs Image performance in Image Editor (720p_30fps_H264-128kbit_AAC).mp4](https://archive.blender.org/developer/F8749238/Blender_2.83_Render_Result_vs_Image_performance_in_Image_Editor__720p_30fps_H264-128kbit_AAC_.mp4) **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

Ludvik Koutny commented

2020-08-04 16:11:17 +02:00

Added subscriber: @Rawalanche

Jeroen Bakker commented

2020-08-04 16:38:05 +02:00

Added subscriber: @Jeroen-Bakker

Jeroen Bakker commented

2020-08-04 16:38:05 +02:00

The image editing drawing is currently under developement #67530. 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 #67530. 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.

Ludvik Koutny commented

2020-08-04 16:43:44 +02:00

In #79518#990438, @Jeroen-Bakker wrote:
The image editing drawing is currently under developement #67530. 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.

> In #79518#990438, @Jeroen-Bakker wrote: > The image editing drawing is currently under developement #67530. 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 commented

2020-08-05 05:23:45 +02:00

Closed as duplicate of #77812

Richard Antalik closed this issue

2020-08-05 05:23:45 +02:00

Ludvik Koutny commented

2020-08-05 09:22:15 +02:00

Added subscriber: @iss

Ludvik Koutny commented

2020-08-05 09:22:15 +02:00

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

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

2020-08-05 10:03:05 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-08-05 10:03:05 +02:00

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

Philipp Oeser reopened this issue

2020-08-05 10:03:05 +02:00

Philipp Oeser commented

2020-08-05 10:03:05 +02:00

Needs another look

Evan Wilson commented

2020-08-05 18:57:51 +02:00

Added subscriber: @EAW

Evan Wilson commented

2020-08-05 18:57:51 +02:00

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.

VSE_0001-1000.mp4

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.

>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. [VSE_0001-1000.mp4](https://archive.blender.org/developer/F8748658/VSE_0001-1000.mp4) --- Here are two screen shot that better duplicate the number of areas in your video. ![16bit_png.png](https://archive.blender.org/developer/F8748662/16bit_png.png) ~10fps with a 16bit png ![8-bit_png.png](https://archive.blender.org/developer/F8748663/8-bit_png.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.

Germano Cavalcante commented

2020-08-05 21:28:00 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-08-05 21:28:00 +02:00

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 #77812

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

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 #77812 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 commented

2020-08-06 03:16:46 +02:00

In #79518#990988, @Rawalanche wrote:
@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 #77812

And as @Jeroen-Bakker 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 @EAW

> In #79518#990988, @Rawalanche wrote: > @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 #77812 And as @Jeroen-Bakker 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 @EAW

Sergey Sharybin commented

2020-08-06 11:35:15 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2020-08-06 11:35:15 +02:00

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

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 #77812 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 #77812 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.

This is in fact caused by the same root cause as the #77812. 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 #77812 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 #77812 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.

Sergey Sharybin commented

2020-08-06 11:47:27 +02:00

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

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 commented

2020-08-07 03:52:03 +02:00

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

Ludvik Koutny commented

2020-08-07 10:13:51 +02:00

In #79518#991828, @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.

> In #79518#991828, @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.

Sergey Sharybin commented

2020-08-07 10:50:07 +02:00

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.

Jeroen Bakker commented

2020-09-11 12:00:33 +02:00

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.

This issue has been addressed by [D8234](https://archive.blender.org/developer/D8234). Please report any new issues as new reports. [D8234](https://archive.blender.org/developer/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 commented

2020-09-11 12:02:37 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Jeroen Bakker closed this issue

2020-09-11 12:02:37 +02:00

Jeroen Bakker self-assigned this 2020-09-11 12:02:37 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Render result drawing performance in Image Editor is extremely poor compared to image texture drawing performance. #79518