Fix on linux

[asny]

See #303 . @iwanders can you test if it works on this branch? 🙏

@coderedart Our glutin/winit update caused some problems on Linux 😬 From the documents it seems that we should choose EglThenGlx instead of GlxThenEgl on linux, but maybe you have some more insights?

[coderedart]

yeah, EglThenGlx caused a lot of problems for users on egui. https://github.com/emilk/egui/issues/2699 https://github.com/emilk/egui/issues/2689 https://github.com/emilk/egui/issues/2457 and more users on egui discord.

glutin devs stated that glx works more often than egl at https://github.com/emilk/egui/pull/2541#issuecomment-1370767582

Although, there's a bunch of other issues mixed in with this problem. If @iwanders can provide backtrace + log ouput at debug level, i think we can find the root cause. Also, the glutin exact version being used in Cargo.lock file.

[iwanders]

Can confirm this change fixes it for me.

@coderedart , I'd like to, I found EGL_LOG_LEVEL=debug and RUST_LOG=debug in the other linked issues, but that doesn't do anything for me as the window initialization creates a result, that is just an Err variant;

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: GlutinError(Error { raw_code: Some(8), raw_os_message: Some("BadMatch (invalid parameter attributes)"), kind: BadMatch })', battleground_viewer/src/lib.rs:77:10
stack backtrace:
   0: rust_begin_unwind
             at /rustc/fc594f15669680fa70d255faec3ca3fb507c3405/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/fc594f15669680fa70d255faec3ca3fb507c3405/library/core/src/panicking.rs:64:14
   2: core::result::unwrap_failed
             at /rustc/fc594f15669680fa70d255faec3ca3fb507c3405/library/core/src/result.rs:1791:5
   3: battleground_viewer::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
ivor$ env | grep LOG
RUST_LOG=debug
EGL_LOG_LEVEL=debug
LOGNAME=ivor

That's with glutin

name = "glutin"
version = "0.30.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "524d807cd49a0c56a53ef9a6738cd15e7c8c4e9d37a3b7fdb3c250c1cd5bf7a3"

Exact failure on this line.

I've checked out egui, and the egui_demo_app starts without any problems when compiled fresh. So that got me thinking...

I dropped my Cargo.lock for my own project, which changed me to glutin 0.30.6;

[[package]]
name = "glutin"
version = "0.30.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "68dc39a51f661324ea93bf87066d62ee6e83439c4260332695478186ec318cac"

With that version, this branch linux-try-fix still works, master now fails in a different way:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: XError { description: "GLXBadWindow", error_code: 182, request_code: 154, minor_code: 32 }', /home/ivor/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.28.1/src/platform_impl/linux/x11/window.rs:1131:14
stack backtrace:
   0: rust_begin_unwind
             at /rustc/fc594f15669680fa70d255faec3ca3fb507c3405/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/fc594f15669680fa70d255faec3ca3fb507c3405/library/core/src/panicking.rs:64:14
   2: core::result::unwrap_failed
             at /rustc/fc594f15669680fa70d255faec3ca3fb507c3405/library/core/src/result.rs:1791:5
   3: winit::platform_impl::platform::x11::window::UnownedWindow::inner_size_physical
   4: three_d::window::winit_window::windowed_context::inner::WindowedContext::from_winit_window
   5: three_d::window::winit_window::Window<()>::new
   6: battleground_viewer::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
ivor$ env | grep -i LOG
RUST_LOG=debug
EGL_LOG_LEVEL=debug
LOGNAME=ivor

Which is arguably even more cryptic. If there's anything I can do to provide more helpful information please let me know.

[coderedart]

Do you not have tracing or logging ? I don't see any log output at all.

[iwanders]

Do you not have tracing or logging ? I don't see any log output at all.

Nope, based on this comment I realised I may need to add a logger xD. I added env_logger and a env_logger::init(); call to my program, now we get some more prints, but they don't provide more information unfortunately:

[2023-02-26T14:45:27Z INFO  winit::platform_impl::platform::x11::window] Guessed window scale factor: 0.9539082845052084
[2023-02-26T14:45:27Z DEBUG winit::platform_impl::platform::x11::window] Calculated physical dimensions: 800x600
[2023-02-26T14:45:27Z ERROR winit::platform_impl::platform] X11 error: XError {
        description: "GLXBadWindow",
        error_code: 182,
        request_code: 154,
        minor_code: 32,
    }
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: XError { description: "GLXBadWindow", error_code: 182, request_code: 154, minor_code: 32 }', /home/ivor/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.28.1/src/platform_impl/linux/x11/window.rs:1131:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
ivor$ env | grep LOG
RUST_LOG=debug
EGL_LOG_LEVEL=debug

[asny]

So to me that looks like a rather generic error. I found this line "GLXBadWindow is generated if the underlying X window for either draw or read is no longer valid." here which doesn't really tell much. Maybe the window is destroyed too early or something? Could also be wrong parameters to the window, it's a bit weird that it has to guess the size?

[asny]

I acknowledge the experience from egui, but since EglThenGlx hasn't been a problem in three-d and GlxThenEgl has caused problems, I'm going to merge this for the upcoming release. If we experience problems with EglThenGlx we can look at again, it's at least very easy to switch 🙂