Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with clip and transform properties when used together. #597

Closed
GiacomoGarbin opened this issue Mar 1, 2024 · 2 comments
Closed

Comments

@GiacomoGarbin
Copy link

GiacomoGarbin commented Mar 1, 2024

Hi.

Issues with clip and transform properties have already been raised (e.g. #253) and they should be fixed in the next release (#594), but I wanted to check that the following case is a real problem or could be a problem with my render interface implementation.

The manual says:

When both a transform and scissor region is active, the scissor region must also have the transform matrix applied for correct results. One solution to this is to draw a rectangle with the position and dimensions of the scissor region into a stencil buffer with the transform applied.

I implemented the suggested solution using the Vulkan backend as an example.

The issue I want to raise is that the transform applied to the scissor region is the transform of the clipped element rather than the transform of the element that generates the clipping area.

Here is an example (clipping_issue.rml.txt):

clipping_issue

In the example there is a 2-level hierarchy. The parent element (red) defines a clipping area with the clip: always property. The child element (orange) is rotated with the transform: rotateZ(30deg) property. The expected result would be to see the child element clipped, but when the scissor region is applied, it is also rotated along the child element, causing the incorrect clipping.

It seems like the solution would be to apply the right transform (if any) to the scissor region, but this requires passing this transform to the render interface backend along the scissor region.

I currently have a workaround in my render interface implementation where I store the last rendered geometry (along with its translation and transform) and use it as scissor region, or better scissor geometry. With this workaround I am also able to solve the problem with the border-radius property mentioned at the beginning. But of course this approach generally breaks with an n-level hierarchy where n is greater than 2 or when the parent element defining the clipping area has more than one child (i.e. the child element has siblings), in this case the expected clipping will generally be applied only to the first child that is rendered after the parent.

Thanks.

@mikke89
Copy link
Owner

mikke89 commented Mar 4, 2024

Hi, thanks for stopping by. Yeah, I would say this is one of the limitations of the old approach, nested transformations and clipping does not really work.

Did you try #594? Hopefully, this situation should simply just work there :) I'm definitely interested in seeing real-world use cases tested:

Improved element clipping behavior. Handles more complicated cases, including nested transforms with hidden overflow, and clips to the curved edge of elements with border-radius. This requires clip mask support in the renderer.

Since that one is about to be merged soon, I am not really going to find workarounds for the old approach. I don't believe that approach scales very well. Your workaround basically describes part of the new design, but the effects branch should also handle n-level hierarchy. This hasn't really been that broadly tested yet especially on real-world test cases, so please feel free to contribute some tests.

@mikke89
Copy link
Owner

mikke89 commented Mar 30, 2024

I believe this should be fixed now that #594 has been merged, please let me know otherwise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants