It seems to me you only need the effective position to implement LinkedViewOp in the client. If so, I wonder whether a lightweight transform feedback machanism would suffice:

package op

// TransformFeedbackOp can retrieve the transformation effective
// at the point of recording into the frame.
type TransformFeedbackOp struct {
     // Transform is filled in with the transformation during processing
     // of the frame the op is recorded into. Transform must not be nil.
     Transform *f32.Affine2D
}

Then, app.Window.Frame will, through the router, fill in Transforms during frame processing where transforms are realized. And you can use the usual app.ViewEvent to update your embedded view.

WDYT?

WDYT?

I didn't observe any bottle-neck calling MoveWindow every frame. In case of lightweight code...
As long as link.Move(...) is called whenever it's expected boundary changes, things should be fine 🔥

WDYT?

I didn't observe any bottle-neck calling MoveWindow every frame. In case of lightweight code... As long as link.Move(...) is called whenever it's expected boundary changes, things should be fine 🔥

What did you think of the rest of my proposal? If it's acceptable, we can avoid having any extra paltform specific code in Gio to support native windows.

WDYT?

I didn't observe any bottle-neck calling MoveWindow every frame. In case of lightweight code... As long as link.Move(...) is called whenever it's expected boundary changes, things should be fine 🔥

What did you think of the rest of my proposal? If it's acceptable, we can avoid having any extra paltform specific code in Gio to support native windows.

To support native window GIO should have platform view api available to it. Since GIO app is expected run on multiple platforms this could be more useful in the long run.
I think I can change some platform specific API calls to that are already available in GIO.

And I also think that having a pointer passed around just for knowing it's boundary a little bit much. But for convenience we may want GIO to know about the underlying platform code.

WDYT?

I didn't observe any bottle-neck calling MoveWindow every frame. In case of lightweight code... As long as link.Move(...) is called whenever it's expected boundary changes, things should be fine 🔥

What did you think of the rest of my proposal? If it's acceptable, we can avoid having any extra paltform specific code in Gio to support native windows.

To support native window GIO should have platform view api available to it. Since GIO app is expected run on multiple platforms this could be more useful in the long run. I think I can change some platform specific API calls to that are already available in GIO.

I'm don't think the platform view API belongs in Gio if it doesn't need to. Like most other projects, we should be diligent about not increasing the long-term maintenance burden, and platform code is always the most troublesome to maintain.

I think having some examples based around it might be enough.