Hi, just submitted a possible fix T84815 : Missing preview image. I would be interested to know if I could have submitted the diff in a better way.

Can we initializeTileData of all input operations in SingleThreadedOperation::executeRegion and pass a span of input buffers to update_memory_buffer?
Later on the concept of initializeTileData won't exist and buffers may be managed by a BufferManager.
To know the rect initializeTileData should render, SingleThreadOperation may have a virtual method "getInputAreaOfInterest(input_index, output_rect)", if not overriden it returns the output rect by default.
determineDependingAreaOfInterest method may be removed, so operations should override this new one when needed.

• Better implement custom move contructor

• Use explicit type
• Add OpenCLDevice move contructor

Looks good to me. I've tested both modes and haven't found any issue. Thanks to this patch it should be easy to know when all readers of an execution group have finished and free its buffer.

Opening it. But not able to reproduce.

I just tested with 2.93.0 Alpha, branch: master, commit date: 2021-04-13 07:49, hash: rB30ee57be60b7 and the problem was still there.

• Merge branch 'master' into temp-compositor-scheduling
• Compostior: Test for break to stop compositing.
• Tweaked InputToOutput scheduling.

This issue has been fixed. I assume some of the tweaks in the threading solved this issue.

Issue was related to T87252

This is a feature request according the rules of the bug tracker.
For feature request please use the appropriate channels.

Looks like some work might be happening on the compositor (exciting!). I started collecting some ideas in a DevTalk thread a while ago, but unfortunately got busy and mostly abandoned it. It might be worth checking it out again.

There is already a mutex guarding multiple calls to OIDN so there is no parallel execution going on. The compositor memory efficiency can be improved and is part of a T81650: New compositor system proposal
I wasn't able to reproduce the pink output or crash.

@Philipp Oeser (lichtwerk) yes this is currently not supported and should be hidden.

We currently have the AA node. From workflow point of view masks can be added and AA afterwards.
For more complex setups use Cryptomatte.

Hmm a bit of a one off issue.

Ah I switched to EEVEE as I was working on a debug build. But somehow there are 5 input socket and the compositor connects them to 9 source.
Next week will look at all the exceptions that have been added for the file output node and see what is failing and what works.

In T87292#1143892, @Jeroen Bakker (jbakker) wrote:

Seems to be unrelated. The issue is that the first connected socket determines the resolution of the output file. As this socket is not connected to anything it just doesn't save the image. Not sure why the mentioned commit is the cause, it seems to be always the case.

Seems to be unrelated. The issue is that the first connected socket determines the resolution of the output file. As this socket is not connected to anything it just doesn't save the image. Not sure why the mentioned commit is the cause, it seems to be always the case.

Assume this is the same as T87252, will merge these reports.

That is fine. The fix was to not delete the matte Id after loading a file. And always update the Id