tmaq
/
tornavis
1
0
Fork 0
Code Issues 2 Pull Requests 29 Packages Projects 24 Releases Wiki Activity

Fix #118555: Occasional incorrect compositor result with relative transform 

In the tiled compositor ensure_delta() can be called from multiple threads,
but without any threading synchronization. This worked fine when the node
only supported absolute transform: multiple threads would do the same work
and assign delta to the same values.

With the addition of relative transform in #115947 a code which adjusts
previously calculated delta was added, leading to possible double-applying
relative transform.

The solution is to avoid multiple threads modifying the same data by using
a double-locked check.

This issue does not happen in 4.2 (main branch) because it switched to full
frame compositor, which works differently.

Pull Request: https://projects.blender.org/blender/blender/pulls/119883
This commit is contained in:
Sergey Sharybin 2024-03-25 18:13:38 +01:00 committed by Sergey Sharybin
parent 26caa18173
commit 6c74d4af15
1 changed files with 9 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
source/blender/compositor/operations/COM_TranslateOperation.h
View File

@ -7,6 +7,8 @@
#include "COM_ConstantOperation.h"
#include "COM_MultiThreadedOperation.h"
#include <mutex>
namespace blender::compositor {
class TranslateOperation : public MultiThreadedOperation {
@ -24,6 +26,8 @@ class TranslateOperation : public MultiThreadedOperation {
bool is_delta_set_;
bool is_relative_;
std::mutex mutex_;
protected:
MemoryBufferExtend x_extend_mode_;
MemoryBufferExtend y_extend_mode_;
@ -60,6 +64,11 @@ class TranslateOperation : public MultiThreadedOperation {
inline void ensure_delta()
{
if (!is_delta_set_) {
std::unique_lock lock(mutex_);
if (is_delta_set_) {
return;
}
if (execution_model_ == eExecutionModel::Tiled) {
float temp_delta[4];
input_xoperation_->read_sampled(temp_delta, 0, 0, PixelSampler::Nearest);