Iced: Panic in clear_measurement_cache

Created on 18 Dec 2019  路  4Comments  路  Source: hecrj/iced

My application panics on startup in iced_wgpu::text::Pipeline::clear_measurement_cache with Trim text measurements: TextureTooSmall { suggested: (512, 512) } (see backtrace below). This started happening when I added a lot more text elements. You can try to reproduce this from https://github.com/Gohla/space_engineers_calc by running cargo run --package secalc_gui_iced --bin secalc_gui_iced -Z unstable-options --profile=debuginfo

thread 'main' panicked at 'Trim text measurements: TextureTooSmall { suggested: (512, 512) }', src\libcore\result.rs:1189:5
stack backtrace:
   0:     0x7ff7adfb71b9 - backtrace::backtrace::trace_unsynchronized
                               at C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.40\src\backtrace\mod.rs:66
   1:     0x7ff7adfb71b9 - std::sys_common::backtrace::_print_fmt
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libstd\sys_common\backtrace.rs:84
   2:     0x7ff7adfb71b9 - std::sys_common::backtrace::_print::{{impl}}::fmt
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libstd\sys_common\backtrace.rs:61
   3:     0x7ff7adfce73b - core::fmt::write
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libcore\fmt\mod.rs:1024
   4:     0x7ff7adfb4144 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libstd\io\mod.rs:1412
   5:     0x7ff7adfb9c99 - std::sys_common::backtrace::_print
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libstd\sys_common\backtrace.rs:65
   6:     0x7ff7adfb9c99 - std::sys_common::backtrace::print
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libstd\sys_common\backtrace.rs:50
   7:     0x7ff7adfb9c99 - std::panicking::default_hook::{{closure}}
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libstd\panicking.rs:190
   8:     0x7ff7adfb98ec - std::panicking::default_hook
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libstd\panicking.rs:207
   9:     0x7ff7adfba4ec - std::panicking::rust_panic_with_hook
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libstd\panicking.rs:466
  10:     0x7ff7adfba060 - std::panicking::continue_panic_fmt
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libstd\panicking.rs:375
  11:     0x7ff7adfb9f49 - std::panicking::rust_begin_panic
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libstd\panicking.rs:304
  12:     0x7ff7adfca4bd - core::panicking::panic_fmt
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libcore\panicking.rs:81
  13:     0x7ff7adfca5bf - core::result::unwrap_failed
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libcore\result.rs:1189
  14:     0x7ff7add5c009 - core::result::Result<glyph_brush::glyph_brush::BrushAction<()>, glyph_brush::glyph_brush::BrushError>::expect
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\src\libcore\result.rs:984
  15:     0x7ff7add5c009 - iced_wgpu::text::Pipeline::clear_measurement_cache
                               at C:\Dev\iced\wgpu\src\text.rs:144
  16:     0x7ff7add2530f - iced_wgpu::renderer::{{impl}}::layout
                               at C:\Dev\iced\wgpu\src\renderer.rs:416
  17:     0x7ff7add2530f - iced_native::user_interface::UserInterface<secalc_gui_iced::app::Message, iced_wgpu::renderer::Renderer>::build<secalc_gui_iced::app::Message,iced_wgpu::renderer::Renderer,iced_native::element::Element<secalc_gui_iced::app::Message, iced_wgpu::renderer::R
                               at C:\Dev\iced\native\src\user_interface.rs:112
  18:     0x7ff7add12bbf - iced_winit::application::Application::run<iced::application::Instance<secalc_gui_iced::app::App>>
                               at C:\Dev\iced\winit\src\application.rs:153
  19:     0x7ff7add46efc - iced::application::Application::run
                               at C:\Dev\iced\src\application.rs:154
  20:     0x7ff7add46efc - secalc_gui_iced::main
                               at C:\Dev\space_engineers_calc\code\gui_iced\src\main.rs:12
  21:     0x7ff7add46e96 - std::rt::lang_start::{{closure}}<()>
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\src\libstd\rt.rs:61
  22:     0x7ff7adfb9ea7 - std::rt::lang_start_internal::{{closure}}
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libstd\rt.rs:48
  23:     0x7ff7adfb9ea7 - std::panicking::try::do_call<closure-0,i32>
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libstd\panicking.rs:289
  24:     0x7ff7adfbdc5c - panic_abort::__rust_maybe_catch_panic
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libpanic_abort\lib.rs:28
  25:     0x7ff7adfba822 - std::panicking::try
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libstd\panicking.rs:267
  26:     0x7ff7adfba822 - std::panic::catch_unwind
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libstd\panic.rs:395
  27:     0x7ff7adfba822 - std::rt::lang_start_internal
                               at /rustc/25d8a9494ca6d77361e47c1505ecf640b168819e\/src\libstd\rt.rs:47
  28:     0x7ff7add46f37 - main
  29:     0x7ff7ae06b760 - post_pgo_initializer
  30:                0x1 - <unknown>
bug

Most helpful comment

Thanks! It's quite a primitive application with just lots of text inputs and outputs :sweat_smile:

For this application I want most things to shrink because text takes up so much space. But I'm not entirely sure what the defaults should be, as I think it depends on the kind of application. Single-line pieces of text (e.g., labels and headers) should probably width-shrink, but I'm not sure about multi-line pieces of text. What is the semantics of width-shrink there anyway, does it shrink at new lines and wrap as late as possible?

For columns and rows, I think it depends again. The outer column/row can width-shrink or have a fixed width, and then the inner ones can fill. Or the other way around (which is what I am doing right now): outer row width-fills, inner columns width-shrink. Maybe shrinking could be a conservative default (with some padding/spacing to ensure things aren't too tight?), and filling would be opt-in. But I'm not sure, as I don't have a lot of experience creating GUI's.

Grid support would be really nice though. I am kind of emulating grids by putting things in rows and giving labels a fixed-width that corresponds to the largest label (determined by experimentation). Grids could take care of this automatically, by width-shrinking the column with labels.

One last thing is that the default text size is kind of large. This is easy to fix with a function that sets a default size though. I understand that styling could fix this at some point. Maybe styling could also influence the (default) filling/shrinking behavior?

In any case, this is a really cool and nicely designed library, great job! I was using gtk-rs before, which of course has much more GUI features, but is a slog to work with because all widget notifications need to be handled in 'static closures which means all state needs to be wrapped in Rc<RefCell<T>>. Compiling and deploying a GTK application is also hell, especially on Windows. With Iced, I can easily compile and deploy a native executable or use the web (i.e., https://secalc.gohla.nl/ for this app). I particularly liked creating a web application without touching a single line of HTML or JavaScript :grinning:

All 4 comments

Thanks for the report! I have been able to reproduce the issue and fix it. PR is on the way!

This is an impressive app you have built! I think it's the most complex one I've seen made in Iced so far.

image

I've noticed you have helper functions to make widgets shrink, I have been thinking about making it the default. Let me know if there are other details you feel could be improved.

It should be fixed by #130.

Thanks! It's quite a primitive application with just lots of text inputs and outputs :sweat_smile:

For this application I want most things to shrink because text takes up so much space. But I'm not entirely sure what the defaults should be, as I think it depends on the kind of application. Single-line pieces of text (e.g., labels and headers) should probably width-shrink, but I'm not sure about multi-line pieces of text. What is the semantics of width-shrink there anyway, does it shrink at new lines and wrap as late as possible?

For columns and rows, I think it depends again. The outer column/row can width-shrink or have a fixed width, and then the inner ones can fill. Or the other way around (which is what I am doing right now): outer row width-fills, inner columns width-shrink. Maybe shrinking could be a conservative default (with some padding/spacing to ensure things aren't too tight?), and filling would be opt-in. But I'm not sure, as I don't have a lot of experience creating GUI's.

Grid support would be really nice though. I am kind of emulating grids by putting things in rows and giving labels a fixed-width that corresponds to the largest label (determined by experimentation). Grids could take care of this automatically, by width-shrinking the column with labels.

One last thing is that the default text size is kind of large. This is easy to fix with a function that sets a default size though. I understand that styling could fix this at some point. Maybe styling could also influence the (default) filling/shrinking behavior?

In any case, this is a really cool and nicely designed library, great job! I was using gtk-rs before, which of course has much more GUI features, but is a slog to work with because all widget notifications need to be handled in 'static closures which means all state needs to be wrapped in Rc<RefCell<T>>. Compiling and deploying a GTK application is also hell, especially on Windows. With Iced, I can easily compile and deploy a native executable or use the web (i.e., https://secalc.gohla.nl/ for this app). I particularly liked creating a web application without touching a single line of HTML or JavaScript :grinning:

It should be fixed by #130.

That indeed fixes it, thanks!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Charles-Schleich picture Charles-Schleich  路  3Comments

Newbytee picture Newbytee  路  4Comments

pbspbsingh picture pbspbsingh  路  4Comments

hecrj picture hecrj  路  3Comments

sumibi-yakitori picture sumibi-yakitori  路  3Comments