You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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):
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 thetransform: 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.
The text was updated successfully, but these errors were encountered: