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

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!
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-rsbefore, which of course has much more GUI features, but is a slog to work with because all widget notifications need to be handled in'staticclosures which means all state needs to be wrapped inRc<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: