Comments (26)
+1 for gfx and wgpu. They seem to be the future.
As for compile times, I agree that having long compile times is annoying, but I'd rather that the back end be correct and well-supported than worry about compile times.
from egui.
Based on the reading I've done, I think gfx-hal or wgpu would give you the best portability/performance in the long run. No idea when it comes to compile times. It would be awesome if there was a really fast (but maybe unsafe) backend that could be used for prototyping an app, then you can switch to a slower backend for production builds. I would guess a minimal OpenGL binding library would be the fastest you can compile in Rust.
from egui.
An alternative to glow and glium that I recently tried out that is very nice is luminance
. It's got a safe and Rusty API and it has desktop and web backends. It's way nicer than using plain OpenGL through glow or other GL wrappers.
from egui.
Because I wanted to support Safari on iOS for my game, I ended up making a glow
backend for Luminance that is able to target WebGL1. Without having tested it, I'm fairly sure that it can also support GL ES 2.x. Maybe not the best idea to have egui depend on my experimental backend that has just been born, but it's there if anybody want's to mess around with it.
It also targets both web and desktop without requring separate backends, so instead of having to have separate GL and WebGL backends of egui we could just have one:
https://github.com/katharostech/luminance-glow
Might be a reasonable direction, for egui
, but I'm not sure. 🤷♂️
from egui.
I'm in the process of making a fork that replaces egui_glium
's glium dependency with glow.
It's not 100% complete yet:
- It has a couple OpenGL texture leaks
- I haven't fully tested it with user textures
- There is an odd graphical glitch where there's a black border around things
Other than that, it seems to work fine:
I plan to fix all remaining problems in the coming days, just putting it out there that I'm working on it, and I can polish it up if there is an interest in merging it once all the ugly bits have been ironed out.
It's at AlexApps99/egui, feel free to give feedback but keep in mind it's still rough around the edges.
Edit: It's worth noting the new code is not very well organized yet, I plan to reorganize it soon and I expect that there should be an increase in performance due to less state changes.
from egui.
First piece of feedback is that we likely want it as a separate crate
egui_glow
next toegui_glium
I'll be sure to do that, but since Git doesn't make very good diffs when files are moved, I will temporarily overwrite egui_glium
while I am working on it, and rebase once I feel it's close to completion
from egui.
I think the first options sounds good, as glow::Context
seems to be made for sharing (it's Sync
and all methods are &self
). Though forcing users to call egui_glow.destroy(&glow_context);
isn't that much of a limitation imho.
For saving state: I'd vote no (at least initially), but document what state is lost.
from egui.
I agree about transparency not being a big problem. The current glium window transparency is not great either (at least on my mac) due to egui using a different blendmode (premul alpha).
I believe most important things when picking a native rendering for eframe
is, in approximate order:
- portability: compiles on all platforms and runs well for all video cards with all drivers
- performance: high FPS / low CPU and GPU usage / battery efficient
- compilation: few dependencies, no
build.rs
(Am I missing something?)
from egui.
An alternative to glow and glium that I recently tried out that is very nice is
luminance
. It's got a safe and Rusty API and it has desktop and web backends. It's way nicer than using plain OpenGL through glow or other GL wrappers.
Luminance is very nice, but currently it supports OpenGL >3.
GUI libraries should support different variants of OpenGL APIs including GL 2.x, GL ES 2.x, and etc.
from egui.
miniquad
may be a reasonable option with a stated goal of fast compilation time. There's already an existing basic implementation that is linked to in this repo's readme.
It has good cross-platform support (notably including mobile and web). Perhaps if its web backend is sufficient, egui
could only need to officially support one integration, although official wgpu
/gfx-hal
and winit
may be useful for adoption, given their prevalence in the Rust graphics ecosystem.
From an egui
integration perspective, it looks like miniquad
should be able to support all of RawInput
, PaintJobs
, and Output
, with the exception of setting the mouse cursor.
from egui.
I haven't looked at miniquad
a lot, but it does seem to have a minimum of dependencies, which is awesome!
Sadly it doesn't seem to have a sRGBA/gamma aware texture format: https://docs.rs/miniquad/0.2.55/miniquad/graphics/enum.TextureFormat.html. This would mean colors will always be a bit off (like they are in egui_web
). This is one thing egui_glium
gets right. I would be hesitant to sacrifice correctness for compilation speed in for the official native Egui backend. I've opened an issue for this: not-fl3/miniquad#166
from egui.
Oops, accidentally closed
from egui.
One disadvantage of miniquad: It does not yet support IME, which is very unfriendly to non-English users. Winit+gfx-hal/wgpu-rs may be the best solution at this stage.
from egui.
I did my own backend with gl_rs (tho it uses some abstraction I have over opengl, so unsafes are a bit more limited). One cool crate I recently found out about is https://github.com/grovesNL/glow so maybe this is also an option if you're looking to keep it available on as many platforms as possible.
from egui.
Can you elaborate if this means your planning on removing support for glium all together? I'm currently writing a project using glium and imgui-rs, and was hoping to switch to egui at some point, but reading this thread has me confused about whether or not that will be possible.
To be clear, I'm just hoping for clarification here. Thanks!
from egui.
I think egui_glium
will stick around as long as it has users, it will just no longer be the default backend for eframe
.
from egui.
I can vouch for glow
being really useful. Seems like a good option to me and it works on web as easily as it does desktop I think. The issue I see with GFX or WGPU is that OpenGL support isn't complete yet.
from egui.
If you switch glium to wgpu backend will need support initialize by vulkan like way
like in a simple sample but extreamly easier than vulkano or ash
from egui.
I also think that glow
is a reasonable choice at least until wgpu
lacks well opengl support (if it ever happens).
The only one big cons related to choicing glow
, that it is a simple wrapper around OpenGL APIs so it unsafe.
from egui.
Good point. Then we could port the Luminance GL backend to use Glow. 😏
from egui.
One disadvantage of miniquad: It does not yet support IME, which is very unfriendly to non-English users. Winit+gfx-hal/wgpu-rs may be the best solution at this stage.
@n2 This is misleading. The winit + gfx-hal/wgpu-rs stack does not support IME either. In fact, close to none of the Rust ecosystem supports IME, because the issue is upstream in winit
(rust-windowing/winit#1497).
from egui.
@lunabunn Yes, you are right. Winit dos not support all IME functions, but what I mean is that by using winit, even if there is no Composition event, one can at least use IME to input non-English characters (such as Chinese characters in my case) . For miniquad, there is no way to do this.
from egui.
Oh, very interesting @AlexApps99 !
First piece of feedback is that we likely want it as a separate crate egui_glow
next to egui_glium
so that we can:
- Test them side by side as competing native backends for
eframe
(perhaps behind a feature flag at first) - Keep
egui_glium
as some are using glium for 3D rendering andegui_glium
for a gui layer (i.e. they aren't usingeframe
).
from egui.
For the texture leaks: would it be better if:
EguiGlow
held a reference toglow::Context
, so everything can be properly destructed on drop (this would create some lifetime restrictions on it)- The functions that overwrite textures (
register_glow_texture
andset_user_texture
) take in an argument forglow::Context
- A
Vec<NativeTexture>
of pending to be deleted textures is stored byEguiGlow
and when a function withglow::Context
is called, they all get deleted - Some other solution?
It's worth noting that the first solution is the only one that would completely avoid leaks, as all remaining objects thatEguiGlow
would be storing on drop would have no way to be deleted unless done manually by the user, or if a reference to context is stored.
Also, do you think it would be worth storing the old OpenGL state and restoring it once painting is complete? It would probably make it take a bit longer to draw but would lead to less bugs when users integrate egui into their code. No idea if other IMGUIs do this, like Dear Imgui
Edit: it seems Dear Imgui does not save and restore state
from egui.
coming from #735 , about using wgpu as the official backend, I just wanted to mention that wgpu transparency support is not yet done. gfx-rs/wgpu#687 . :(
from egui.
That's a shame, but it doesn't sound like a deal-breaker, when web doesn't support it, and most integrations will not need it.
from egui.
Related Issues (20)
- eframe demo panic on startup
- Feature to get target refresh rate HOT 4
- Not detecting mouse release after alt-tab on windows
- egui_glow's winit feature should be enabled on wasm
- Context Menus demo crashes on negative width or height HOT 1
- Add ability to disable hover tooltip on TextWrapping HOT 2
- Chinese can be entered in the first position of text_editor, but not in other positions HOT 20
- egui_plot formatter, spacer etc. should not need to be 'static
- Update to `winit` 0.30 HOT 4
- Send non zero repaint delay due to animation.
- Dead keys seem to be broken on mac HOT 1
- Dragging windows allows cursor to become detached from original location
- Window position creeps between executions on scaled monitors
- Pan Zoom and Strip Demo overlap bug HOT 2
- Transparency not working with Egui/Eframe HOT 9
- ComboBox menu doesn't report its actual size to its closure HOT 2
- Transparency not working depending on the Screen it is created on HOT 1
- Stacked bars are offset by a wrong value
- Porting egui to ereaders. Issue with text sizes after update from 13.1 to 27.2 HOT 8
- `with_always_on_top` causes window to display incorrectly when window size is equal to screen size HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from egui.