compositor performance issue when larger empty area surrounding the image #112526

New Issue

michael campbell · 2023-09-18T15:20:16+02:00

michael campbell commented

2023-09-18 15:20:16 +02:00

System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 536.99

Blender Version
Broken: version: 4.0.0 Alpha, branch: main, commit date: 2023-09-10 22:17, hash: fca8df9415b1
Worked: much faster in 2.93

Short description of error
compositor performance is severely degraded if there is a larger empty area surrounding the pixels. Also becomes more and more sluggish the longer it plays back, despite it only updating a single image block. Task manager doesn't show any increase in memory usage as it becomes slower.

Exact steps for others to reproduce the error
Get an image sequence to playback in the compositor's backdrop, either with a image sequence node, or by updating a single image via python and calling render.render to force the playhead to wait for the compositor to finish calculating. Try playing back with the compositor contracted and expanded. See video for demonstration.

Issue affects the tiled, full frame, and gpu compositor modes. Also happens when experimental compositor is disabled completely in the preferences.

Example video attached.

**System Information** Operating system: Windows-10-10.0.19044-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 536.99 **Blender Version** Broken: version: 4.0.0 Alpha, branch: main, commit date: 2023-09-10 22:17, hash: `fca8df9415b1` Worked: much faster in 2.93 **Short description of error** compositor performance is severely degraded if there is a larger empty area surrounding the pixels. Also becomes more and more sluggish the longer it plays back, despite it only updating a single image block. Task manager doesn't show any increase in memory usage as it becomes slower. <video src="/attachments/a4e3035c-8c8f-4956-9689-769b1d26300f" controls></video> **Exact steps for others to reproduce the error** Get an image sequence to playback in the compositor's backdrop, either with a image sequence node, or by updating a single image via python and calling render.render to force the playhead to wait for the compositor to finish calculating. Try playing back with the compositor contracted and expanded. See video for demonstration. Issue affects the tiled, full frame, and gpu compositor modes. Also happens when experimental compositor is disabled completely in the preferences. Example video attached.

2023-09-18 14-12-58.mp4

42 MiB

michael campbell added the

labels 2023-09-18 15:20:17 +02:00

Germano Cavalcante commented

2023-09-18 21:15:05 +02:00

I'm not sure what needs to be done to replicate the problem.
I made this file, but I'm still not able to reproduce the problem described.

I'm not sure what needs to be done to replicate the problem. I made this file, but I'm still not able to reproduce the problem described.

seq_compositor_update_in_playback.blend

767 KiB

Germano Cavalcante added

Status

Needs Information from User

and removed

Status

Needs Triage

labels 2023-09-18 21:15:14 +02:00

michael campbell commented

2023-09-19 11:37:41 +02:00

Hi @mano-wii . I've created a simple file to replicate the issue more easily. Please note, render.render is only used to force the timeline to wait until the compositor finished execution. This was done so the fps reported by the 3d viewport accurately describes what's happening. Without render.render (using viewer node .update() instead), the issue persists.

Steps:

Open the attached file, and load with 'load ui' option enabled
go to the 'small area' workspace and press play
looks at the fps shown in the 3d viewport editor below it. On my system it's 20fps initially
now switch to the large area workspace. The fps will roughly half (depending on your screen size, i'm on 4k. On 1080p the performance reduction won't be as pronounced.
keep it playing for a while, switching back and forth between the workspaces
notice how after playing back for a minute or so, the fps drops to roughly half it was when initially loading the file.
close the file and re-open, now the fps should be fast again.

Hi @mano-wii . I've created a simple file to replicate the issue more easily. Please note, render.render is only used to force the timeline to wait until the compositor finished execution. This was done so the fps reported by the 3d viewport accurately describes what's happening. Without render.render (using viewer node .update() instead), the issue persists. Steps: 1. Open the attached file, and load with 'load ui' option enabled 2. go to the 'small area' workspace and press play 3. looks at the fps shown in the 3d viewport editor below it. On my system it's 20fps initially 4. now switch to the large area workspace. The fps will roughly half (depending on your screen size, i'm on 4k. On 1080p the performance reduction won't be as pronounced. 5. keep it playing for a while, switching back and forth between the workspaces 6. notice how after playing back for a minute or so, the fps drops to roughly half it was when initially loading the file. 7. close the file and re-open, now the fps should be fast again.

update image in compositor bug.rar

57 MiB

michael campbell commented

2023-09-19 11:40:55 +02:00

oh, and a recursion happens if relying on

if not bpy.app.is_job_running('RENDER'):

It doesn't seem to prevent the frame change handler being entered for some reason. That's why I had to resort to a global variable. Potentially another bug?

oh, and a recursion happens if relying on ``` if not bpy.app.is_job_running('RENDER'): ``` It doesn't seem to prevent the frame change handler being entered for some reason. That's why I had to resort to a global variable. Potentially another bug?

Iliya Katushenock added the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

compositor performance issue when larger empty area surrounding the image #112526