This adds all parts of the web "location" (URL) to frame.info().web_info, included a HashMap of the query parameters, percent-decoded and ready to go.
This lets you easily pass key-value pairs to your eframe web app.
* egui_web: use tracing crate
* egui_glow: use tracing crate
* Log at the debug level
* egui_demo_app: enable tracing to log to stdout
* Use tracing in egui-winit
* Add opt-in tracing support to egui
* Move texture allocation into epaint/egui proper
* Add TextureHandle
* egui_glow: cast using bytemuck instead of unsafe code
* Optimize glium painter
* Optimize WebGL
* Add example of loading an image from file
* Replace `std::time::Instant` with wasm-compatible `instant::Instant`
* Change version requirement for instant to be compatible to winit
* Enable wasm-bindgen feature for instant
* Update lockfile
* Update changelog
* sort dependencies
Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
`begin_frame`, `end_frame` is more convenient when using egui in a game engine. In particular, 0.16.0 was incompatible with https://github.com/mvlabat/bevy_egui>.
* Move window building to egui-winit
* Move icon loading to egui-winit
* `use glow::HasContext;` -> `use glow::HasContext as _;`
* Move FileStorage into epi behind a feature flag
* De-duplicate screen_size_in_pixels and native_pixels_per_point
* Move creation of FileStorage to epi
* Handle epi app output (window size changes etc) in egui-winit
* Move app and memory persistence and autosave logic to egui-winit
* fix check.sh
* Make the epi backend opt-in for egui_glium and egui_glow
* Fix persistence
* Add integration name to epi::IntegrationInfo and the demo
* Clean up Cargo.toml files and fix making egui_glium optional
* fix typo
* Make egui_glium compile without the `epi` feature
* Make egui_glow and opt-in backend for eframe
* Add egui_glow to Cargo.toml and to CI
* Reference egui_glow where egui_glium is mentioned
* Remove path-patches from root Cargo.toml
* Add instructions on how to enable the glow backend of eframe
* Speed up galley cache by only using the hash as key
This hashes the job but doesn't compare them with Eq,
which speeds up demo_with_tessellate__realistic by 5-6%,
winning back all the performance lost in
https://github.com/emilk/egui/pull/682
* Remove custom Eq/PartialEq code for LayoutJob and friends
* Silence clippy
* Unrelated clippy fixes
I've extracted all the http request code and turned it
into its own crate at <https://github.com/emilk/ehttp>.
There was never a reason for the HTTP request library to be part of
`eframe`. Much better to have it as its own crate!
This PR introduces a completely rewritten text layout engine which is simpler and more powerful. It allows mixing different text styles (heading, body, etc) and formats (color, underlining, strikethrough, …) in the same layout pass, and baked into the same `Galley`.
This opens up the door to having a syntax-highlighed code editor, or a WYSIWYG markdown editor.
One major change is the color is now baked in at layout time. However, many widgets changes text color on hovered. But we need to do the text layout before we know if it is hovered. Therefor the painter has an option to override the text color of a galley.
## Performance
Text layout alone is about 20% slower, but a lot of that is because more tessellation is done upfront. Text tessellation is now a lot faster, but text layout + tessellation still lands at a net loss of 5-10% in performance. There are however a few tricks to speed it up (like using `smallvec`) which I am saving for later. Text layout is also cached, meaning that in most cases (when all text isn't changing each frame) text tessellation is actually more important (and that's more than 2x faster!).
Sadly, the actual text cache lookup is significantly slower (300ns -> 600ns). That's because the `TextLayoutJob` is a lot bigger (it has more options, like underlining, fonts etc), so it is slower to hash and compare. I have an idea how to speed this up, but I need to do some other work before I can implement that.
All in all, the performance impact on `demo_with_tesselate__realistic` is about 5-6% in the red. Not great; not terrible. The benefits are worth it, but I also think with some work I can get that down significantly, hopefully down to the old levels.