-
Notifications
You must be signed in to change notification settings - Fork 117
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
Update to current-ish glazier. #118
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems straight-forward, LGTM, thanks!
I'd like to hear from someone that uses Unix... I've only run the basic example on Windows so far. |
(I'm not in a big rush here as I'm looking at linebender/glazier#127...) |
Yeah, tested it on NixOS (Linux), so only OSX is remaining (and web) I guess? |
Trying it out on macOS now. |
Well, that's interesting. On my (old-ish, x86_64) MacBook Pro, prior to the update, the example runs okay (not great). After the update, it is noticeably laggy and performs poorly. I did install a system update today, so the system is still cleaning up after that and running a long backup cycle, but it doesn't feel like this is the reason. If I run an example from the glazier repo, it runs fine. Running the vello |
Okay, the macOS issue is related to this commit by @lord: linebender/glazier@58cd5a4 In
And below that:
And in the patch linked above, that was changed to remove most of that ... Making a similar update here fixes the macOS performance issue. This is a good argument for updating Glazier more often here. :) |
bbc1145
to
baf4442
Compare
@Philipp-M The updated changes now work on both macOS and Windows. Can you give it another shot on Linux when you have the chance, please? |
It panics now unfortunately: Backtrace
|
That panic is kind of unavoidable with Glazier's current design of I think we might end up with a straightforward AOS |
Why didn’t that panic before then? |
Because we only had one backend enabled at a time before, so there wasn't the ambiguity of which kind of menu needed to be created. This is an API design problem in glazier - similar to the monitors API. |
baf4442
to
343741b
Compare
Okay, I understand now. I've pushed an update to move the construction around a bit that should fix this panic for now. @Philipp-M / @DJMcNab if either of you can confirm that it no longer crashes on Linux, then we can merge this? |
Just tested it, while not panicking straight away, input didn't work (clicking) and after I have resized the window a little bit this panic came: Backtrace
|
Do you get input-related debug output from running the |
Yes I get output, something like this:
|
I don't want to boot up my Linux machine ... Not sure what my next step will be. |
The Input not working on Linux with this PR is because the Newer The next step for this PR would be to rebase on Ultimately, to have input working on all platforms, the solution is to refactor the Xilem code to use the new pointer API instead of the old mouse API. That would be the solution for both the |
f6c833f
to
d040fec
Compare
Updated to the current |
The change to `app_main.rs` matches a similar change made in the Glazier examples. Also, since we now have both x11 and wayland backends on some platforms, we need to make sure that we create the application prior to creating the menu. This will be improved in future versions of Glazier. This minimally updates to the PointerEvent API within Glazier as that has replaced the MouseEvent API.
d040fec
to
a28ef8b
Compare
@xStrom Thanks for your work in pushing me to get this over the finish line! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested on Fedora, Windows 10, and Mac OS. The hello example worked for all of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confirmed working. Thanks for your efforts!
This helps pave the way for updating Xilem to use pointer events.