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

Work in progress xilem prototype #1

Merged
merged 7 commits into from
Nov 23, 2022
Merged

Work in progress xilem prototype #1

merged 7 commits into from
Nov 23, 2022

Conversation

raphlinus
Copy link
Contributor

This is a snapshot of the current state of the xilem prototype built on new infrastructure: glazier for window creation, piet-gpu for drawing, and parley for text.

As of this snapshot, only the text widget has been ported, and there are a number of rough edges. It should be considered a proof of concept. That said, it should be possible to build more from here.

This is a snapshot of the current state of the xilem prototype built on new infrastructure: glazier for window creation, piet-gpu for drawing, and parley for text.

As of this snapshot, only the text widget has been ported, and there are a number of rough edges. It should be considered a proof of concept. That said, it should be possible to build more from here.
DJMcNab added a commit that referenced this pull request Nov 16, 2022
I've chosen not to deny warnings in CI because we currently have warnings.

Once #1 lands, we can enforce cleanliness of warnings
@DJMcNab DJMcNab mentioned this pull request Nov 16, 2022
DJMcNab added a commit that referenced this pull request Nov 17, 2022
We don't deny warnings in CI because we currently have warnings.

Once #1 lands, we can enforce cleanliness from warnings

See also linebender/glazier@d0b9e19
as we only use windows at the moment
@ghost
Copy link

ghost commented Nov 17, 2022

Text is blurry.

Screenshot 2022-11-17 at 13 47 04

Is high DPI detection enabled/implemented?

@dzhou121
Copy link

dzhou121 commented Nov 17, 2022

I guess this question is more for piet-gpu, but how are we going to manage the text rendering on different platforms? Like you'll probably need sub-pixel rendering for Windows, but not necessary for Macs.

@ghost
Copy link

ghost commented Nov 17, 2022

@dzhou121 don't know if that's useful, but we had a small convo about text rendering here

@dzhou121
Copy link

https://xi.zulipchat.com/#narrow/stream/296640-font-tech/topic/Pathfinder.20approach.20vs.2E.20defer.20to.20native

Thanks. I can see it's a discussion of the mechanisms of text rendering. My question is more user level, i.e. does text look the same or different across different OS, or Xilem will expose some API for you to choose.

@ghost
Copy link

ghost commented Nov 17, 2022

Hm. I suppose we can always expose a config to, say, enable font dilation on Windows or sub-pixel rendering on Mac, but generally I'd say it defaults to replicating the platform's native way of rendering fonts.

@raphlinus
Copy link
Contributor Author

Blurry text is tracked in linebender/glazier#26, it's a DPI scaling problem.

Regarding glyph rendering, that is a question for piet-gpu, and a very interesting one. I just wrote linebender/vello#204 to capture my current thoughts. It's subject to discussion, and may well affect a decision of when and whether to depend on this stack.

raphlinus and others added 3 commits November 20, 2022 22:03
This is a mostly working button implementation, but the background (a gradient) isn't rendering yet. When it is, I'll likely merge the PR.
This adds the rendering of the gradient to the button widget.

The "piet_scene_helpers" module is a bit hacky, we'll need to have some discussions about how to handle kurbo shape types more easily. But it should work for now.
@raphlinus raphlinus marked this pull request as ready for review November 21, 2022 18:17
@Psykopear
Copy link
Contributor

Psykopear commented Nov 21, 2022

Trying this on Linux with Gnome/Wayland.

The main.rs runs, I see the button with the gradient background, but if I click on it I get no message on stdout.
I can't close the window normally (x button or shortcut to close window) I have to ctrl+c from the terminal.

edit: It was running on wayland but as an X client, if I try to run with "wayland" feature on glazier it panics:

    Finished release [optimized] target(s) in 0.07s
     Running `target/release/xilem`
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/docler/repos/xilem/src/app.rs:205:24
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[wayland-client error] A handler for wl_pointer panicked.
fish: Job 1, 'cargo run --release' terminated by signal SIGABRT (Abort)
xilem on new_infra is 📦 v0.1.0 via 🦀 v1.65.0 took 4s x 

@raphlinus
Copy link
Contributor Author

Thanks for trying it! I haven't tested on anything but mac yet. The lack of mouse sensitivity sounds like a problem, we'll need to investigate it.

I'm not sure what exactly is wrong with quitting, that appears to be a glazier issue (the code in xilem is adding the quit item to the menu).

The panic on Wayland looks similar to this observation. Again I think the best place to fix this is glazier.

@Psykopear
Copy link
Contributor

Psykopear commented Nov 21, 2022

Right, I also get no menu, so maybe that's related, but I see no logs in the console that could help:

image

Edit: Running the glazier example I see that menus are not implemented yet, so that's not an issue with this PR.

2022-11-21T19:39:44.889418Z  WARN glazier::backend::x11::menu: Menu::new is currently unimplemented for X11 backend.
2022-11-21T19:39:44.889459Z  WARN glazier::backend::x11::menu: Menu::add_item is currently unimplemented for X11 backend.
2022-11-21T19:39:44.889471Z  WARN glazier::backend::x11::menu: Menu::add_item is currently unimplemented for X11 backend.
2022-11-21T19:39:44.889476Z  WARN glazier::backend::x11::menu: Menu::add_item is currently unimplemented for X11 backend.
2022-11-21T19:39:44.889481Z  WARN glazier::backend::x11::menu: Menu::new is currently unimplemented for X11 backend.
2022-11-21T19:39:44.889485Z  WARN glazier::backend::x11::menu: Menu::new is currently unimplemented for X11 backend.
2022-11-21T19:39:44.889496Z  WARN glazier::backend::x11::menu: Menu::add_dropdown is currently unimplemented for X11 backend.
2022-11-21T19:39:44.889503Z  WARN glazier::backend::x11::menu: Menu::add_dropdown is currently unimplemented for X11 backend.

@DJMcNab
Copy link
Contributor

DJMcNab commented Nov 21, 2022

Testing on Windows 10 with AMD Ryzen 3600 and GTX 1050ti, leads to the window not responding before I can take any actions.
Running the file in a debugger gives a few observations:
Building the window takes quite a while. Showing the window is instant, but once the window is shown we never get to app_main:83. I.e. something in window.show() hangs. This appears to be UpdateWindow.
My best guess is that UpdateWindow is waiting for the messages to be processed, which can't happen because the thread is waiting for them.
Bizarrely, the first frame? is drawn, despite this.

@raphlinus
Copy link
Contributor Author

I've tested the glazier-shello example on Windows, but not the integration with piet-gpu. Unfortunately, I'm at the office right now without easy access to a Windows machine. I can take another look when I get home.

@raphlinus
Copy link
Contributor Author

raphlinus commented Nov 22, 2022

I do repro the "render one frame then hang" behavior with Windows, and also note that it's the same with glazier-shello. This is very likely a glazier problem and I can probably track it down.

Small update: https://github.com/dfrg/piet-gpu/tree/dshell/examples/shello had this working correctly on Windows (using the unpiet branch of druid-shell), and something broke along the way to the latter becoming glazier. It should be possible to track down either through looking at what changed, or debugging the current state.

@raphlinus
Copy link
Contributor Author

The Windows hang is fixed by linebender/vello#207. The reason the shello example worked is that the branch predated the robust memory work. So this was not in fact a glazier problem.

@jplatte
Copy link
Contributor

jplatte commented Nov 22, 2022

On actual wayland (glazier/wayland feature), I got a panic (and transparent window):

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/jplatte/code/xilem/src/app.rs:205:47
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[wayland-client error] A handler for wl_pointer panicked.

With the gtk feature, glazier didn't compile at all.

Allow selecting the glazier backend on Linux
@jplatte
Copy link
Contributor

jplatte commented Nov 22, 2022

It wasn't my intention to get my PR merged into this one without Raph's consent, so in case that is unwanted, please just force-push away and I'll re-open / re-create my PR after this is done.

@raphlinus
Copy link
Contributor Author

No worries, it's all good. Very likely it'll be helpful for fixing and validating the panic on Wayland, which I intend to do later today.

Should fix crashes on Wayland in particular.

Also snap to newer deps, which should fix hang on Vulkan.
@raphlinus
Copy link
Contributor Author

We should now be able to handle window events before the first paint. Also I snapped Cargo.lock to newer github versions. There's lots to do still (including some work on dpi that I'm seeing), but I'm wondering if this might now be "good enough" to merge, and future work on top of it.

@flxzt
Copy link

flxzt commented Nov 22, 2022

I have an eGPU ( Nvidia GTX 1080 ) I can connect to my laptop (Intel HD graphics) so I am able to test a couple of different configurations:

  • with X11 and nvidia: It runs, but panics as soon as I try to resize the window:
    thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ERROR_OUT_OF_DATE_KHR', src/render.rs:118:18
  • with X11 / xwayland and integrated graphics: the window stays black and I can only quit with Ctrl+C in the terminal
  • with wayland and integrated graphics: Transparent window..

hope this helps. on windows it runs now for me!

@raphlinus
Copy link
Contributor Author

Thanks for the reports. We're going to switch to wgpu soonish, so it doesn't make sense to go too deep into compatibility issues just now, though it would make sense to fix obvious breakage.

@Psykopear
Copy link
Contributor

Ok, now the x11 backend works. It takes some time (~1 second) to get from window creation to the button appearing, but then both the button and closing the window work.

With the wayland backend, I get an invisible window and no logs in stdout. But, if I hit the shortcut to close the window, it quits correctly.

Same behaviour with intel integrated and rtx3050

Copy link
Contributor

@dfrg dfrg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excited to land this!

@raphlinus raphlinus merged commit ef1d907 into main Nov 23, 2022
@DJMcNab DJMcNab deleted the new_infra branch November 23, 2022 18:43
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.

None yet

8 participants