Issue was caused by the way how render result was acquiring -- pointer
to render data was used to find needed render descriptor. It's not
reliable since render contains copy of scene's render data, not pointer
to this data.
Use node scene's id name for render result acquiring, the same way
as it was done in old compositor system.
Now supports output value of:
- Absolute marker position
- Marker position relative to the very first marker
- Marker position relative to given scene frame
Seems to be simple non-initialized buffer used in math, but additional
check would be welcome here.
At least now result doesn't seems to be corrupted and seems to behaving
the same way as non-tile compositor.
for a color combine (mix) node with render resolution at 100%
Seems to be that the MaskNode has been created as a complex node. But no
complex features were used. Converted the execute pixel to simple
execution. And it sees that the crash does not happen.
Not sure if it is the issue is solved. I am going to let the user retest
with this revision.
* [#32040] size-input of a blur-node is uniform for the whole picture
* [#32062] Blur node Size input is not working with
* [#32140] Blur Node using a greyscale input as size multiplier fails
to work
Node now has a new option (new compositor cannot detect if the connected
part is a single value, or an image connected).
With this option the use of a reference image to multiply the size of
the blur per pixel can be enabled/disabled.
Regards,
Jeroen
- At Mind -
Issue was caused by threading conflict between compositor output node which
is freeing buffers used by render result image and image draw code which
could use buffers at the same time as compositor frees this buffers.
Solved by adding adding lock around viewer image invalidation and image
drawing.
Use renamed LOCK_PREVIEW mutex for this, which si not called LOCK_DRAW_IMAGE.
With new compositor locking for preview is not needed so it could be removed.
Added the same lock around viewer operation which also frees buffers used
by viewer image. It's actually quite difficult to check whether this is
indeed needed. This code seems to be using acquire/release technique, but
somehow acquiring ImBuf before invalidating it in compositor operation
doesn't resolve the issue, so probably it's not actually locking acquire
and things should be checked deeper.
