Add render transform to Control nodes

[timoschwarzer]

This is an implementation of my proposal outlined in this discussion: godotengine/godot-proposals#7053 (comment)

tl;dr: Currently it's hard and complicated to animate Control nodes without breaking the layout, especially if the Control nodes are in deeply nested layout structures which is often the case. This PR adds new properties to Control nodes that specify a render transform that does not affect and is not affected by layouting (similar to CSS' transform). These make UI animations much less pain to work with

• render_offset: translation
• render_scale: scale
• render_rotation, rotation
• render_transform_pivot, pivot for scaling and rotating

render_offset and render_transform_pivot are relative to the size of the Control node by default (I think it's a very common usecase to rotate around and scale from the center) but it can be toggled to use absolute pixel values instead.

Screencast.from.2024-01-11.17-10-13.webm

Considerations

Input is currently not affected by the render transform. That means if you e.g. apply a render offset to a button, the button is still clickable at its original position but drawn somewhere else. This might need some discussion whether that's desirable or not.

[fire]

I remember Node2D has properties.

Vector2 | position | Vector2(0, 0)
float | rotation | 0.0
Vector2 | scale | Vector2(1, 1)

How are these different?

Edit:

Will review the proposal.

[Mickeon]

One could argue that both render_rotation and render_scale are not that useful since (unless I'm severely mistaken) Controls already ignore both rotation and scale within containers and when moving anchors/margins.

[timoschwarzer]

@Mickeon this is currently considered a bug: #19068

That's why I added rotation and scale render transforms separately although they have the same result currently :)

[Mickeon]

I've gotten so used to the bug it may as well be a feature to me. 5 years ever since it has been reported, too. This "bug" does have its advantages in the same exact way as render_offset does in the PR. Hmm...

[timoschwarzer]

@Mickeon yeah, that's why I added render_rotation. So if the bug with rotation gets fixed eventually, people who used it for animation can switch to render_rotation and people who want rotated controls to actually use more space can finally do that. Same for scale and render_scale.

[djrain]

How this would affect children of the animated node, if at all? In our games we're usually animating whole control-based scenes or Containers, like a playing card or something, frequently containing both Controls and Node2D, so the whole thing needs to be animated as a unit. I currently achieve that by applying an animation transform to the node but only after any parent Container does its layout.

[timoschwarzer]

@djrain the current implementation sets the CanvasItem transform of the Control node, so it affects all children as well.

[timoschwarzer]

@AThousandShips thanks for the review 🙌 applied everything and fixed code style issues

[timoschwarzer]

@AThousandShips now it should have everything except the px suffix

[Mickeon]

Two things:

• You should add these lines (and ideally roughly document them) in Control.xml otherwise that Linux build will never compile
  
• When the PR is in "Draft" state it means it is not ready for review. I don't know if this is intentional.

[timoschwarzer]

@Mickeon thanks for noticing, I was aware of it! I had a small fun project using the changes of this PR going on until today hence I didn't write the docs yet and didn't remove the WIP status. I'll get this PR ready in the next days hopefully.

[timoschwarzer]

@Mickeon I added the docs and removed the WIP status so the PR should be ready for review now 🙂

[Mickeon]

That's good, I... hmm... This is not a review but some thoughts:

• This PR could've used a separate proposal to further discuss potential solutions to the issue.
  • I probably should've recommended this much sooner, but everyone has their own things to worry about.
• The PR as is adds a LOT of properties to all Controls, which is most certainly hefty. It does introduce overhead, yet a grand majority of Control nodes in your standard application are not going to make use of them, or at least not all the time.
  • Because of it, in my opinion, it's worth being careful if this PR is even considered as is. Of course as you can see everyone is desiring something like this, but having it for every Control may be excessive. There may be multiple solutions to the same issue worth evaluating.

[Calinou]

Tested locally, it works as expected. There's the question of whether we should shift input coordinates as well, but this isn't always desired if you're using this for animation purposes. For instance, when hovering an UI element and shifting it upwards, if you held your mouse cursor on the bottom edge of the element, you could end up in a situation where the UI element is being hovered and unhovered continuously in a loop. Not shifting input coordinates prevents this kind of situation, at the cost of less a precise idea of where you can actually click the button (particularly for rotated buttons).

godotengine/godot-proposals#4338 would be a particularly good pairing with this PR, so that you can easily extend the clickable area of your buttons to cater for the space they can take during an animation.

Testing project: test_pr_87081.zip

cards.mp4

[timoschwarzer]

@Mickeon I can only speak for myself, but I've had more use for the newly added properties in contrast to existing position, rotation and scale properties. In addition to that, the point of this PR is to make all Controls easily animatable without messing with layouting. I don't see why only some Controls should have the render transform properties and some shouldn't (where would you draw the line here?).

I didn't measure it but I can't imagine the overhead being even noticable. The final transform is not calculated every frame but is cached iirc.

[conde2]

First of all, amazing pull request, indeed very useful.

I would only suggest to check if you're not setting the same value in the setters. To avoid a calling notify and a queue draw.

[markdibarry]

Also, rotation already has limited use with controls since clip_contents is not compatible.