Path Colour does not follow its rotation

[Erinaaaaaaa]

When rotating a path drawable (not its points) whether directly or by rotating its parent, the Colour of the path will not follow the rotation:

0° rotation:

90° rotation:

180° rotation:

After some investigation, this also happens with SmoothPath and TexturedPath (which I assume is because they both are derived from Path)

Current solution in which the problem can be seen: https://github.com/Jeremiidesu/ProjectDiba ; Behavior can be found in the GameDrawable -> Note visual test, with Rotation being Entry Angle - 90°

[bdach]

This is not surprising behaviour in a sense. These are all how a textured quad (going from opaque white to transparent left-to-right) masked to the path would look like.

This is more of a feature request to add support for adding support for colour gradients which follow the path.

[smoogipoo]

That would make sense if the colour was applied to the parent. But in this case the colour and rotation are both applied to the path, and so the colour is also expected to be rotated (as happens with a normal box).

[smoogipoo]

This is also an issue with BufferedContainer.

It turns out that this is quite hard to fix. Basically, BufferedDrawNode always draws itself to the screen as an AABB with true colour while and its child DrawNode rotates within the FBO with a white colour.

So what if the children receive the real colour? Well that that runs into several problems itself:

1. Blending from BufferedContainer is currently broken (https://github.com/ppy/osu-framework/issues/3429).
2. We currently depend quite a bit on children of BufferedContainer not receiving the parenting alpha as it is our only way to merge layers. This may still be possible but we need to figure out how to achieve the layer merging effect. Perhaps we can alpha test or double buffer, either way it needs more thought.

Another solution is to make the child DrawNode not rotate, but this is also doesn't seem to be trivial. Finally, perhaps it's possible to calculate the rotated ColourInfo and apply it to the AABB. I don't know whether this is logically sound in general though.