Realtime Compositor: Immediately realize transformations #112332
This patch immediately realizes the scale and rotation components of
transformations at the point of transform nodes. The translate component is
still delayed and only realized when really needed to avoid clipping.
Transformed results are always realized in an expanded domain that avoids
clipping due to rotation or scaling. The size of the transformed domain is
clipped to the GPU texture size limit for now until we have support for huge
textures, that limit is typically 16k.
A potential optimization is to join all consecutive transform and realize
operations into a single realize operation.
This patch immediately realizes the scale and rotation component of transformations at the point of transform nodes, as per the discussion in #108944.
A consequence of that change is that rotated tiles are now impossible to achieve using the Translate Wrapping mechanism.
Also, since the wrapping mode is inherited by transform nodes down the node tree, the user might not get an alpha background. But this is less of an implication of this patch and more an implication of the design of the wrapping mechanism in the compositor.
Package build started. Download here when ready.
I always found wrapping a bit hard to follow because of its inheritance. Would it be possible to make it non-inheritable, applied immediately, and added to the Transform node?
@Sergey It can't be applied immediately, since wrapping technically just specifies the method of realizing on a domain, "on a domain" being the keyworkd here. So that's not possible, but we always use a None wrapping method when realizing transforms if we choose to.
"On a domain" is the current implementation. And to me this is kind of confusing. So the idea was to not set it on a domain, and apply it immediately. So if you translate by 100px you'll immediately get an image with the translation and wrapping applied, without attempting to chain it with other nodes (and this is why we would need the option on the Transform node).
Surely, it could break some compatibility, but it does seem to simplify mental model.
But this would remove the ability to create a repeating pattern like was possible before. Would that be acceptable?
I think it still would be possible if the Wrap option is added to the Transform node.
If I understand correctly, immediate realization of wrapping is essentially what the Full Frame compositor already does. And it is not possible to make a repeating pattern in that case, this was described in "Section 7: Wrapping" in the comparison document, in particular, see figure 17.
To compensate for the lost functionality with repeating, it would be nice to add a wrapping mode option to the Transform node.
To me it also seem we can add option to the transform node, and repeat when scaling is used. That fits the current semantic better.
If that's the only known downside i think it is easier to move on with the patch, and add option as needed.
- Should we immediately apply translation if wrapping is enabled in a "clip on one side, wrap on the other side" fashion?
- Should we fill the empty areas after rotation based on wrapping options?
- Should we ignore wrapping in future domain realizations, and hence lose the ability to do repetitions?
- Should we also add the Wrapping options to the Rotate node?
Should we immediately apply translation if wrapping is enabled in a "clip on one side, wrap on the other side" fashion?
Should we fill the empty areas after rotation based on wrapping options?
I think so.
In theory, it will make the transform code more generic: "just" apply matrix transform with wrapping option enabled.
Should we ignore wrapping in future domain realizations, and hence lose the ability to do repetitions?
Ignore the wrapping in the future domain indeed.
Wrapping can be brought back by adding wrapping option to the Transform node, and doing scale operation there. This would fit closer to the current paradigm of compositor.
Alternatively (something I am not fully convinced in) we can add Repeat/Tile node. This is how some compositing tools do it, but it has its drawbacks.
Regardless, adding more options to other nodes or adding new nodes should be done as separate PR. I do not see it a stopper for this incremental step.
Should we also add the Wrapping options to the Rotate node?
I think all transformation nodes can have it. But it is something to tackle separately from this PR.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?