Iced: All Examples: thread 'main' panicked at 'assertion failed: `(left == right)`

[DLFW]

Hi! Total Rust noob here. Using Arch and an AMD GPU.

First, I could not start any example because of

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/instance.rs:474:5

I could fix that by installing Vulkan.

But now, I'm facing another Issue: Example apps start, but as soon as I move my mouse cursor over the example’s window, the app breaks with

>>>cargo run --package styling
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
     Running `target/debug/styling`
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `0`,
 right: `1`', /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/hub.rs:120:9
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: rust_begin_unwind
   7: std::panicking::begin_panic_fmt
   8: <wgpu_native::hub::Storage<T,I> as core::ops::index::Index<I>>::index
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/hub.rs:120
   9: wgpu_native::command::command_encoder_begin_render_pass::{{closure}}
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:266
  10: core::option::Option<T>::map
             at /build/rust/src/rustc-1.42.0-src/src/libcore/option.rs:450
  11: wgpu_native::command::command_encoder_begin_render_pass
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:264
  12: wgpu_command_encoder_begin_render_pass
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:739
  13: wgpu::CommandEncoder::begin_render_pass
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.4.0/src/lib.rs:1059
  14: <iced_wgpu::window::backend::Backend as iced_native::window::backend::Backend>::draw
             at ./wgpu/src/window/backend.rs:81
  15: iced_winit::application::Application::run::{{closure}}
             at ./winit/src/application.rs:317
  16: winit::platform_impl::platform::sticky_exit_callback
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.22.0/src/platform_impl/linux/mod.rs:698
  17: winit::platform_impl::platform::x11::EventLoop<T>::run_return
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.22.0/src/platform_impl/linux/x11/mod.rs:310
  18: winit::platform_impl::platform::x11::EventLoop<T>::run
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.22.0/src/platform_impl/linux/x11/mod.rs:406
  19: winit::platform_impl::platform::EventLoop<T>::run
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.22.0/src/platform_impl/linux/mod.rs:645
  20: winit::event_loop::EventLoop<T>::run
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.22.0/src/event_loop.rs:148
  21: iced_winit::application::Application::run
             at ./winit/src/application.rs:200
  22: iced::application::Application::run
             at ./src/application.rs:177
  23: iced::sandbox::Sandbox::run
             at ./src/sandbox.rs:128
  24: styling::main
             at examples/styling/src/main.rs:8
  25: std::rt::lang_start::{{closure}}
             at /build/rust/src/rustc-1.42.0-src/src/libstd/rt.rs:67
  26: std::panicking::try::do_call
  27: __rust_maybe_catch_panic
  28: std::rt::lang_start_internal
  29: std::rt::lang_start
             at /build/rust/src/rustc-1.42.0-src/src/libstd/rt.rs:67
  30: main
  31: __libc_start_main
  32: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Any clue?

[hecrj]

Could you try the examples in wgpu-rs and report if they also panic for you? If they do, the issue is most likely upstream.

[DLFW]

Hi! Just checked. At least all examples from wgpu-rs’ current master work fine.

[hecrj]

Let's discard a fix, could you try the examples in the 0.4 branch?

[DLFW]

0.4 doesn't compile at all:

   Compiling wgpu v0.4.0 (/home/daniel/sandbox/foreign/wgpu-rs)
error[E0599]: no method named `hidpi_factor` found for struct `winit::window::Window` in the current scope
  --> examples/cube/../framework.rs:69:35
   |
69 |         let hidpi_factor = window.hidpi_factor();
   |                                   ^^^^^^^^^^^^ method not found in `winit::window::Window`

error[E0599]: no method named `to_physical` found for struct `winit::dpi::PhysicalSize<u32>` in the current scope
  --> examples/cube/../framework.rs:70:40
   |
70 |         let size = window.inner_size().to_physical(hidpi_factor);
   |                                        ^^^^^^^^^^^ method not found in `winit::dpi::PhysicalSize<u32>`

error[E0599]: no variant or associated item named `EventsCleared` found for enum `winit::event::Event<'_, _>` in the current scope
   --> examples/cube/../framework.rs:164:27
    |
164 |             event::Event::EventsCleared => {
    |                           ^^^^^^^^^^^^^
    |                           |
    |                           variant or associated item not found in `winit::event::Event<'_, _>`
    |                           help: there is a variant with a similar name: `MainEventsCleared`

error[E0599]: no method named `to_physical` found for struct `winit::dpi::PhysicalSize<u32>` in the current scope
   --> examples/cube/../framework.rs:137:37
    |
137 |                 let physical = size.to_physical(hidpi_factor);
    |                                     ^^^^^^^^^^^ method not found in `winit::dpi::PhysicalSize<u32>`

error: aborting due to 4 previous errors

For more information about this error, try `rustc --explain E0599`.
error: could not compile `wgpu`.

I looked for a 0.4.3 tag, but it seems there are none...

[hecrj]

Oh, damn. You may be able to get it to compìle by pinning the winit version. Try changing this line in Cargo.toml to:

winit = "=0.20.0-alpha4"

Basically, just add an = in front of the version.

[DLFW]

Here we go... same assertion violation as with iced:

     Running `target/debug/examples/cube`
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `0`,
 right: `1`', /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/hub.rs:120:9
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: rust_begin_unwind
   7: std::panicking::begin_panic_fmt
   8: <wgpu_native::hub::Storage<T,I> as core::ops::index::Index<I>>::index
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/hub.rs:120
   9: wgpu_native::command::command_encoder_begin_render_pass::{{closure}}
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:266
  10: core::option::Option<T>::map
             at /build/rust/src/rustc-1.42.0-src/src/libcore/option.rs:450
  11: wgpu_native::command::command_encoder_begin_render_pass
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:264
  12: wgpu_command_encoder_begin_render_pass
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:739
  13: wgpu::CommandEncoder::begin_render_pass
             at src/lib.rs:1059
  14: <cube::Example as cube::framework::Example>::render
             at examples/cube/main.rs:330
  15: cube::framework::run::{{closure}}
             at examples/cube/../framework.rs:166
  16: winit::platform_impl::platform::sticky_exit_callback
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0-alpha4/src/platform_impl/linux/mod.rs:693
  17: winit::platform_impl::platform::x11::EventLoop<T>::run_return
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0-alpha4/src/platform_impl/linux/x11/mod.rs:305
  18: winit::platform_impl::platform::x11::EventLoop<T>::run
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0-alpha4/src/platform_impl/linux/x11/mod.rs:389
  19: winit::platform_impl::platform::EventLoop<T>::run
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0-alpha4/src/platform_impl/linux/mod.rs:640
  20: winit::event_loop::EventLoop<T>::run
             at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0-alpha4/src/event_loop.rs:148
  21: cube::framework::run
             at examples/cube/../framework.rs:126
  22: cube::main
             at examples/cube/main.rs:357
  23: std::rt::lang_start::{{closure}}
             at /build/rust/src/rustc-1.42.0-src/src/libstd/rt.rs:67
  24: std::panicking::try::do_call
  25: __rust_maybe_catch_panic
  26: std::rt::lang_start_internal
  27: std::rt::lang_start
             at /build/rust/src/rustc-1.42.0-src/src/libstd/rt.rs:67
  28: main
  29: __libc_start_main
  30: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

So, this has to be considered a bug in dependency? Is there another, maybe more stable/mature backend?

[hecrj]

So, this has to be considered a bug in dependency?

Yes. However, as you pointed out, it seems to be fixed in the master branch of wgpu.

Is there another, maybe more stable/mature backend?

Not yet! This is one of the main shortcomings I want to tackle in the near future. It shouldn't be too hard to put everything together, but I believe the Rust ecosystem is currently missing essential pieces:

• A crate to easily obtain a surface from a raw-window-handle for rendering (using either hardware or software). There is promising work happening in surfman! Once these changes land, I think it should be possible to build backends with raqote, piet and/or skia.
• A crate unifying font parsing, text shaping, and text rendering (ideally in a backend-agnostic way). glyph-brush is great, but only supports TTF and does no shaping whatsoever. I believe we should keep an eye on allsorts and rustybuzz which seem to be tackling both parsing and shaping.

[DLFW]

Hm, alright, thanks for the quick support!

A SW/HW agnostic layer in the middle would be great.
I’m thinking about a new programming project (graphical application but with an unconventional UI ─ GTK etc. not feasible), and even I don’t know Rust yet, it seems to be the most feasible language for what I want. But when creating a free application, of course one wants to have a hassle free way for others to join and even more important, the user to just download and use it, without any struggle, on whatever machine they have. I guess there is still a way to go for the Rust ecosystem.

Directly using piet and skia came to my mind already. But good font-rendering and font support is a key requirement for me. I was thinking about Druid and Conrod, but ‐ if possible ‐ I would like to have something which puts a little less load on the CPU. Their examples sometimes seem to take 5% on one core, even without any relevant activity. :) Especially Conrod seems to be CPU-hungry.

However, I will try to build the iced examples with a later version of wgpu and keep an eye on this lib. Thanks again!

[perlindgren]

Any progress on this matter. I'm in the same boat, want to try it out under Arch linux, but got stuck.

[sphinxc0re]

Same problem here under Manjaro

[zicklag]

@hecrj https://github.com/servo/surfman/pull/172 just got merged, so create_native_widget_from_rwh should be available when surfman 0.2 is released.

[hecrj]

@zicklag Awesome!

I have been playing with it the last few days, but I haven't been able to get it to render anything on my environment. As I mentioned in https://github.com/gfx-rs/gfx/pull/3151#issuecomment-612346369 and https://github.com/servo/surfman/issues/173, all I see is a black window on X11. And on Windows, the threads example crashes with a segmentation fault.

I am not familiar with the details of surfman, so I'd appreciate it if someone could reproduce and/or investigate this issue further. I think the Rust graphics ecosystem will benefit considerably from this library.

[zicklag]

Oh, bummer! Unfortunately I only have one machine to test on and it works on that one ( AMD graphics card without extra drivers installed other than what came with the Pop!_OS system ). Plus I don't now much about how surfman does what it does or why it would be broken. Hopefully someone will be able to figure it out.

Now that it is being worked into wgpu and gfx the interested audience will probably grow and it might help get more people interested who might be able to help fix it, too.

[green7ea]

I had this problem when using the lastest version of iced in the Cargo.toml file (version = "*"). I was able to fix it by using the current ice master:

iced = { path = "../iced", features = ["async-std"] }

I believe a newer version of wgpu in iced master fixes the issue.

[hecrj]

This should be fixed by the new OpenGL renderer implemented in #354.