Paths not visible when children of Groups

[johnoneil]

I've been struggling on this issue for a couple of days, so I'll try to describe it methodically. I think I've got it pinned down, but I could be wrong.

I'm currently working on a fix and may present that shortly. I'm open to any questions or suggestions to debug/further explore this issue.

it's also possible there may be a fix on the client side. Not 100% sure yet. I'll take that option if possible.

I believe this issue may be at least partially related to issue #244 . A fix for this issue may also help clarify that (and hopefully not break things!).

First, this is the Figma element we're dealing with. There is a parent node, then a child group (g24) which is offset from the parent, and then a bunch of child paths.

When I render this on the client side, using the path absolute position for translation, and the (accumulated) parent transforms, we see an offset creeping into the paths. Like in the following image.

As you can see from the image, the individual paths are drawn correctly, and their general arrangement is okay, but they are offset incorrectly.

I believe the origin of this issue is this section in transform_flexbox.rs

            let r = r.post_translate(euclid::vec3(
                -(bounds.x() - parent_bounds.x()),
                -(bounds.y() - parent_bounds.y()),
                0.0,
            ));

This section tries to remove translation from the relative_transform matrix provided by figma. That is, it removes (leading minus signs) the offset from the local rect bounds from its parent.

However there are cases when this will be incorrect. I'm referring to this doc here:

https://www.figma.com/plugin-docs/api/properties/nodes-relativetransform/#:~:text=The%20relative%20transform%20of%20a,group%20or%20a%20boolean%20operation.

Note the section:

The relative transform of a node is shown relative to its container parent, which includes canvas nodes, frame nodes, component nodes, and instance nodes. Just like in the properties panel, it is not relative to its direct parent if the parent is a group or a boolean operation.

So in our case, since the immediate parent is a Group (g24) the translation data present in the relative_transform matrix will not be entirely removed. Instead we should be "removing" translation data from the (further offset!) goup g24's parent.

Okay I'm going to try out fixes for this, but I think the approach will be to carry around not just the parent but also a last_relative_transform_parent as we traverse the tree. In most cases these will be the same node, but in these edge cases they will be different.

Will update when I have more.

[johnoneil]

Update:

Okay in a Figma test doc I added some cases reproducing this issue. Note the red "airbag" telltales near the bottom:

But when I render in the validation-app I see the following (this is on main).

So I'm calling this bug Paths not visible when children of Groups.

With a fix to the issue as described above (adjusting the transform member to remove translations from the correct parent`) the issue was not fixed.

I believe this will take a deeper dive into the .kt renderer to see why this is the case.

Generally I'm going to recommend not adjusting transforms coming out of Figma. I'm taking that approach currently and am finding it somewhat simpler. In other words, maybe we could transition the transform member to take the unadjusted relative_transform data.

[johnoneil]

Just to update this bug.

The change I landed above allows the current Rust (impeller based) renderer to work around this bug, but it's still present in Android.

I thought I had a correction that should fix the Android side as well, but that simply didn't work (see the screenshots above). I believe it will take some deeper digging to find out why that fix didn't work.

It's probably moot since we ought to be moving towards shared rendering code, so that any (major) differences in renderers should go away. If this issue becomes a priority on Android I can take a look and perhaps help land a fix.

For the moment I'd suggest leaving this bug, and closing this when we land shared rendering code.

[timothyfroehlich]

Let's get this reproduced and in Validation so that we can confirm that it's fixed at some point

[timothyfroehlich]

@johnoneil Do you still have this reproduced somewhere?

[johnoneil]

Yikes. I think this has been resolved for some time. Sorry to leave it open.
Closing as we haven't seen this in a while.