You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I'm writing a program that pulls in egui for the GUI, and isn't a pure egui app, so I'm using egui_glow rather than eframe. I want it to work on both native and web, with minimal differences between the code paths. winit supports both. As such, I'd like to use the winit feature of egui_glow, but it's disabled for wasm.
Describe the solution you'd like
I'd like the winit feature enabled in egui_glow when wasm is selected.
I don't think this will cause problems for people who don't expect this, since to see a change you need to be pulling in egui_glow with the winit feature while compiling for wasm, and then you just get a few extra functions compiling which presumably get dead code elimination if not used.
It looks like this disabling was added in #1303, and is no longer required?
Describe alternatives you've considered
Currently I'm just using a hacked local fork of egui_glow. I guess I could just not use egui_glow::winit on any platform, but that rather defeats the point of it existing.
Additional context
Using egui_glow and winit on wasm is, TBH, much messier than eframe. If you don't get the canvas.{width,height} and canvas.style.{width,height} set correctly for the devicepixelratio, egui renders incorrectly, and by default it doesn't cope with the browser zoom changing.
There are probably other known shortcomings compared to eframe, but I've not tried doing anything fancy, so haven't encountered them yet.
It might be that we want to fix these before enabling egui_glow::winit on wasm. Or it might be good enough right now and better than nothing (certainly the case for me).
I could also rustle up a demo for this, probably by adding some conditional compilation code to pure_glow.rs, if that's helpful?
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I'm writing a program that pulls in egui for the GUI, and isn't a pure egui app, so I'm using
egui_glow
rather thaneframe
. I want it to work on both native and web, with minimal differences between the code paths.winit
supports both. As such, I'd like to use thewinit
feature ofegui_glow
, but it's disabled for wasm.Describe the solution you'd like
I'd like the
winit
feature enabled inegui_glow
when wasm is selected.I don't think this will cause problems for people who don't expect this, since to see a change you need to be pulling in
egui_glow
with thewinit
feature while compiling for wasm, and then you just get a few extra functions compiling which presumably get dead code elimination if not used.It looks like this disabling was added in #1303, and is no longer required?
Describe alternatives you've considered
Currently I'm just using a hacked local fork of
egui_glow
. I guess I could just not useegui_glow::winit
on any platform, but that rather defeats the point of it existing.Additional context
Using
egui_glow
andwinit
on wasm is, TBH, much messier thaneframe
. If you don't get thecanvas.{width,height}
andcanvas.style.{width,height}
set correctly for thedevicepixelratio
, egui renders incorrectly, and by default it doesn't cope with the browser zoom changing.There are probably other known shortcomings compared to
eframe
, but I've not tried doing anything fancy, so haven't encountered them yet.It might be that we want to fix these before enabling
egui_glow::winit
on wasm. Or it might be good enough right now and better than nothing (certainly the case for me).I could also rustle up a demo for this, probably by adding some conditional compilation code to pure_glow.rs, if that's helpful?
The text was updated successfully, but these errors were encountered: