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

eframe use egui-winit for both native and web #2023

Open
luiswirth opened this issue Sep 7, 2022 · 4 comments
Open

eframe use egui-winit for both native and web #2023

luiswirth opened this issue Sep 7, 2022 · 4 comments

Comments

@luiswirth
Copy link
Contributor

luiswirth commented Sep 7, 2022

I believe that eframe should use egui-winit for both native and web. eframe should in my opinion be like my old crate eww (egui + winit + wgpu) (doesn't has to be wgpu). Meaning that eframe is only a wrapper around a platform crate (winit) and a renderer crate (wgpu, glium or glow).

This would streamline the egui ecosystem a lot I believe.
Currently the step from eframe to a custom integration is still quite big. This would hopefully make this process a lot easier.
This could probably also avoid code duplication in eframe as you wouldn't have to handle wasm support separately as winit would do it for you.

As mentioned in discord I got my own egui + winit + wgpu integration running on wasm. I know it's way to early to now make the switch to only using winit. But I think this goal is worth pursuing. I'll first provide an example like you @emilk asked on discord for #1755.

This was referenced Sep 7, 2022
@emilk
Copy link
Owner

emilk commented Sep 7, 2022

I agree that this is something worth investigating, but before we do we must first get egui-winit to work on web (#1032). Once we have egui-winit working on web (with a working example in the egui repository) we can evaluate whether or not we should switch to it for eframe. You mention a lot of upsides (all of which I agree with), but there are some potential downsides:

A) more reliance on winit, making it more difficult to try out alternatives (like https://github.com/tauri-apps/tao)
B) an extra layer (more overhead, more compilation time, with its own quirks, more difficult for us to fix, etc, etc)

@luiswirth
Copy link
Contributor Author

I agree with everything you said.

@luiswirth
Copy link
Contributor Author

luiswirth commented Sep 22, 2022

As mentioned on discord, I got my application called carveout, which uses a custom egui + wgpu + winit integration, running on the web using wasm. You can check out a live web demo on https://lwirth.com/. It's a digital pen note taking application.

@coderedart also managed to create a running egui + wgpu + winit setup using his egui toolkit etk. Check out their live web demo https://coderedart.github.io/etk/!

In my setup I noticed some things aren't working right now:

  • There is a scaling issue with the cursor position in my UI. For the drawing canvas I directly process winit events which works perfectly fine but the egui cursor pos is wrong for some reason. This doesn't happen with etk.
  • Multi-Touch doesn't work
  • On chrome mobile the website is just blank.

I haven't investigated these problems so far.

@HactarCE
Copy link
Contributor

What's the latest on this issue? My app Hyperspeedcube uses egui+winit+wgpu and works very well, with the only issues I notice being:

  • copy/paste doesn't work on some browsers, such as Firefox (could probably be worked around using JS hooks but I'm not particularly knowledgeable there)
  • I have not implemented automatic dark/light theme detection

It even gets scancodes + virtual keycodes for key input! My app uses both depending on the context.

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

No branches or pull requests

3 participants