Panic in software renderer when shrinking window

[tronical]

To reproduce:

• Start the gallery with SLINT_BACKEND=software and --features slint/renderer-winit-software
• Resize the window to become a little bigger
• Shrink the window again

Panic:

thread 'main' panicked at 'range end index 1871172 out of range for slice of length 1870940', /Users/simon/src/slint/internal/core/software_renderer.rs:1023:22

FWIW it's not a regression against v1.0.0 or even older releases AFAICS.

[ogoffart]

I can't reproduce :-( (tried both the native and fluent style, on linux x11)

[tronical]

I can trivially reproduce it on macOS, but under Linux it's indeed much harder. Under KDE I can reproduce it, but it needs a fair amount of drawing the resize handle of the window back and forth, until eventually it triggers.

[tronical]

This patch applied to the gallery improves the probability for me to hit the panic: https://gist.github.com/tronical/b52e651c45fd16aa6357449fe9cdcae8

[ogoffart]

This is basicaly the same panic as #2027:
In short: the size of the buffer passed to the SoftwareRenderer::render function is too small for the size of the window according to the width and height of the window.
The software renderer will use the WindowItem's size and render that.

The winit backend use the actual size of the window as returned by slint::Window::size(), to allocate a buffer.

When resizing, we might get a frame where the sizes are not in sync and cause the problem.

What to do?

• Should we panic early with better panic message in render() when the buffer is not big enough (suggested by mcu-board-support: Panic if the window size is larger than the display size #2027)
• Or should we instead "clip" the part that is too small to render?
• Why is are the sizes not in sync? Is that a problem of out API which is too easy to misuse?

[ogoffart]

Commit 5fde19d fixed the original issue.
But there are still crashes in other parts of the software renderer.
For example

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/olivier/.cargo/registry/src/index.crates.io-6f17d22bba15001f/euclid-0.22.9/src/size.rs:323:25
stack backtrace:
[...]
   4: euclid::size::Size2D<T,U>::cast
             at /home/olivier/.cargo/registry/src/index.crates.io-6f17d22bba15001f/euclid-0.22.9/src/size.rs:323:9
   5: euclid::rect::Rect<T,U>::cast
             at /home/olivier/.cargo/registry/src/index.crates.io-6f17d22bba15001f/euclid-0.22.9/src/rect.rs:518:39
   6: i_slint_core::software_renderer::SoftwareRenderer::render::{{closure}}
             at ./internal/core/software_renderer.rs:258:21
   7: i_slint_core::window::WindowInner::draw_contents::{{closure}}
             at ./internal/core/window.rs:719:17

(often reproducable when recizing while on the TextEdit pane)

or

thread 'main' panicked at 'index out of bounds: the len is 2273512 but the index is 2273515', /home/olivier/slint/internal/core/software_renderer/draw_functions.rs:64:32
stack backtrace:
[...]
   3: i_slint_core::software_renderer::draw_functions::draw_texture_line
             at ./internal/core/software_renderer/draw_functions.rs:64:32
   4: <i_slint_core::software_renderer::RenderToBuffer<T> as i_slint_core::software_renderer::ProcessScene>::process_shared_image_buffer
             at ./internal/core/software_renderer.rs:1015:13
   5: <i_slint_core::software_renderer::SceneBuilder<T> as i_slint_core::item_rendering::ItemRenderer>::draw_cached_pixmap::{{closure}}
             at ./internal/core/software_renderer.rs:1982:17
   6: i_slint_backend_qt::qt_widgets::QImageWrapArray::draw
             at ./internal/backends/qt/qt_widgets.rs:140:9
   7: <i_slint_backend_qt::qt_widgets::groupbox::NativeGroupBox as i_slint_core::items::Item_vtable_mod::Item>::render::{{closure}}

(this is with the native style)

They seem to relate to the computation of the geometry from floating point may be one pixel off resulting in too small or too big rectangle that takes pixel outside of their source. (esp with a scale factor)