* basic working wgpu @ webgl on websys
* fix glow compile error
* introduced WebPainter trait, provide wgpu renderstate
* WebPainterWgpu destroy implemented
* make custom3d demo work on wgpu backend
* changelog entry for wgpu support eframe wasm
* remove temporary logging hack
* stop using pollster for web
we're actually not allowed to block - this only worked because wgpu on webgl doesn't actually cause anything blocking. However, when trying webgpu this became an issue
* revert cargo update
* compile error if neither glow nor wgpu features are enabled
* code cleanup
* Error handling
* Update changelog with link
* Make sure --all-features work
* Select best framebuffer format from the available ones
* update to wasm-bindgen 0.2.83
* Fix typo
* Clean up Cargo.toml
* Log about using the wgpu painter
* fixup wgpu labels
* fix custom3d_wgpu_shader ub padding
* remove duplicated uniforms struct in wgsl shader for custom3d
* Update docs: add async/await to the web 'start' function
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
* egui_demo_app: remove wgpu and pollster as direct dependencies
* eframe: use same web-sys version as wgpu crate
* Make note that web_sys_unstable_apis is required by the wgpu crate
* Rename the glow web painter in eframe
* Remove trait DummyWebGLConstructor from web_glow_painter.rs
* cargo fmt
* Fix check.sh
I have gone back and forth on this a bit, but I think the arguments
AGAINST following the system theme are many:
* `dark-light` is a big dependency with problems on Linux.
* Many people prefer the dark mode and ask how to set it as the default
(even though they are using light mode in their OS).
* A developer may be surprised when the app changes theme when
they run it on another computer.
So, the path of least surprise is to make this an opt-in feature
with dark mode as the default mode.
On native, you add the `dark-light` feature to enable it.
On web, you set `WebOptions::follow_system_theme`.
