Can not run official example with error NoAvailablePixelFormat... #2018
Comments
|
glxinfo, which opengl version? @rikonaka try add: egui/examples/hello_world/Cargo.toml [dependencies]
eframe = { path = "../../crates/eframe" }
tracing-subscriber = "0.3"egui/examples/hello_world/src/main.rs #![cfg_attr(not(debug_assertions), windows_subsystem = "windows")] // hide console window on Windows in release
use eframe::egui;
fn main() {
// Log to stdout (if you run with `RUST_LOG=debug`).
tracing_subscriber::fmt::init();
let options = eframe::NativeOptions::default();
eframe::run_native(
"My egui App",
options,
Box::new(|_cc| Box::new(MyApp::default())),
);
}
struct MyApp {
name: String,
age: u32,
}
impl Default for MyApp {
fn default() -> Self {
Self {
name: "Arthur".to_owned(),
age: 42,
}
}
}
impl eframe::App for MyApp {
fn update(&mut self, ctx: &egui::Context, _frame: &mut eframe::Frame) {
egui::CentralPanel::default().show(ctx, |ui| {
ui.heading("My egui Application");
ui.horizontal(|ui| {
ui.label("Your name: ");
ui.text_edit_singleline(&mut self.name);
});
ui.add(egui::Slider::new(&mut self.age, 0..=120).text("age"));
if ui.button("Click each year").clicked() {
self.age += 1;
}
ui.label(format!("Hello '{}', age {}", self.name, self.age));
});
}
}and then: export RUST_LOG=debug
cargo run -p hello_worldlet's see what happens. |
|
Not OP, but I have the exact same error. Here's the output that was asked for. Configuration details: When I run unbelievable as it may be, methinks this is possibly an NVIDIA/Wayland problem. |
|
Also not the OP, but I ran into this exact same problem. Config: I am running Gnome 42 (which I suppose runs on Wayland). I get the same thing as @tyrumus My |
|
reference: rust-windowing/glutin#913 can people who have this issue please post the following: my details: Output of output of I was able to confirm this bug on fully up to date arch wayland (both gnome and plasma) with my nvidia. can others verify that glfw/sdl2 are working fine? git clone https://github.com/coderedart/etk.git
cd etk/crates/egui_backend
RUST_LOG=trace cargo run --example=hello --features=winit,glow run hello with winit and glow features combo. change winit to glfw or sdl2 to check that glow works with both of them |
|
for me, it seems the issue lies with winit/glutin: winit,wgpu => works, but wgpu surface doesn't have a srgb supporting format :( glfw or sdl2 with glow or wgpu => works normally including srgb framebuffer support. |
|
Distro: Arch Linux (latest) Here's the debug information requested. Probably not the results that were expected either.
behavior: no window is ever created. behavior: a window is created, and then immediately closed. behavior: the window is created behavior: no window is ever created. behavior: no window is ever created. behavior: a window is created, different from before. Not sure if that's expected. |
|
yeah. I guess the main issue for wgpu is that a window created with winit and sdl2 is not providing a srgb surface format. only The main issue for glow is that glutin is unable to create an opengl window on wayland properly. I will check on my amd iGpu laptop to see if this is an nvidia specific issue or just a wayland issue in general. |
|
Just a bit of digging around. On my system, the failure appears to be caused in (this is in It appears that requiring At that point, the app showed up just fine. So I guess in my case the bug involves Wayland + NVIDIA + vsync. |
|
For the record, here is my The queried parameter |
|
This is the issue in |
|
yeah, I can confirm that if i set double buffer to false and vsync to false. i get a window. the main issue seems to be that when glutin tries to get the MAX_SWAP_INTERVAL with GetConfigAttrib function, it returns zero in all configurations :( . so, you are forced to set vsync to off. so, we just wait for rust-windowing/glutin#1444 in a new release i guess. |
|
Thanks for digging into this everyone ❤️ |
|
Since currently nvidia drivers have various issues on wayland. since both glfw and sdl2 using x11 by default, telling winit to use x11 might help: fn main() {
#[cfg(all(unix, not(target_os = "macos")))]
std::env::set_var("WINIT_UNIX_BACKEND", "x11");
let options = eframe::NativeOptions::default();
eframe::run_native(
"Using x11",
options,
Box::new(|_cc| Box::new(MyApp::default())),
);
} |
|
I also stumbled over this glutin bug in Slint and confirm that it is fixed in the master branch of glutin. 🎉 |
|
I have some question. run eframe template |
Merged
|
try testing with glutin upgrade.
git clone clone https://github.com/coderedart/egui_glutin_upgrade.git
git switch glutin_upgrade
WINIT_UNIX_BACKEND=x11 cargo run --release -p egui_demo_app
WINIT_UNIX_BACKEND=wayland cargo run --release -p egui_demo_app
cargo run --release -p egui_demo_appdon't forget to run these with |
I try run step 3 and run step 4 get the same error: |
|
My system infomation:
|
|
@WanderQing forgot about Windows. anyway, try again with the latest commits. |
I reverted the commit (2e453ef), Run steps 3, 4, 5 are ok. |
|
that's just master branch ? :) |
Yes, it is looks like this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
As my title say...
To Reproduce
Steps to reproduce the behavior:
cargo run -p hello_worldExpected behavior
Run and show a gui.
Screenshots
Desktop (please complete the following information):
Additional context
No.
The text was updated successfully, but these errors were encountered: