Replace Glium

[emilk]

Glium is a convenient choice, but is a rather big dependency which compiles slowly, and uses build.rs. It is also no longer actively maintained.

The ideal choice for compiling Egui natively would be something simple that compiles quickly. I'm not sure there is such an alternative though.

One alternative worth investigating is pure glutin (which Glium depend on). It is a bit lower level compared to Glium, and requires use of unsafe, but it looks easy enough to use: https://gist.github.com/matthewjberger/9da00592b472b50ec1e6b3238719264b

[tangmi]

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.

[emilk]

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

[anderspitman]

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.

[ckaran]

+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.

[emilk]

Oops, accidentally closed

[n2]

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.

[AlexEne]

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.

[bjadamson]

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!

[emilk]

I think egui_glium will stick around as long as it has users, it will just no longer be the default backend for eframe.

[zicklag]

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.

[KentaTheBugMaker]

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

[katyo]

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.

[zicklag]

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.

[katyo]

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.

[zicklag]

Good point. Then we could port the Luminance GL backend to use Glow. 😏

[zicklag]

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. 🤷‍♂️

[lunabunn]

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).

[n2]

@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.

[AlexApps99]

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.

[emilk]

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 and egui_glium for a gui layer (i.e. they aren't using eframe).

[AlexApps99]

First piece of feedback is that we likely want it as a separate crate egui_glow next to egui_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

[AlexApps99]

For the texture leaks: would it be better if:

• EguiGlow held a reference to glow::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 and set_user_texture) take in an argument for glow::Context
• A Vec<NativeTexture> of pending to be deleted textures is stored by EguiGlow and when a function with glow::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 that EguiGlow 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

[emilk]

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.

[coderedart]

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 . :(

[AlexApps99]

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.

[emilk]

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?)