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

[Windows] Implement basic platform view. #90

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

hanswered
Copy link

@hanswered hanswered commented Jul 21, 2022

This is my implementation of win32 platform view.
To fix https://todo.sr.ht/~eliasnaur/gio/428

@hanswered hanswered changed the title Implement basic platform view. [Windows] Implement basic platform view. Jul 22, 2022
@eliasnaur
Copy link
Contributor

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?

@hanswered
Copy link
Author

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 🔥

@eliasnaur
Copy link
Contributor

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.

@hanswered
Copy link
Author

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.

@hanswered
Copy link
Author

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.

@eliasnaur
Copy link
Contributor

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.

@hanswered
Copy link
Author

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

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

Successfully merging this pull request may close these issues.

2 participants