Excessive redraw/dirty areas on pointer events (swrender on embedded)

[bobziuchkovski]

Bug Description

What is the bug?

PointerReleased/PointerExited events after clicking a button result in the full screen being re-rendered and marked as dirty with the software renderer.

What behavior did you expect, and what happened instead?

I expected only the button area to be rendered and marked dirty on release, but instead the full screen is being rendered and marked dirty. This occurs only on PointerReleased/PointerExited. The PointerPressed event on the button does exactly what I'd expect -- render and mark only the button area as dirty, including the subsequent animation updates of the button area.

Steps to reproduce the issue

Dispatch a series of PointerPressed, PointerReleased, and PointerExited events to a button, noting the resulting dirty areas from SoftwareRenderer::render when redrawing.

Any error messages or logs, if available.

My app log output. Note that the initial SoftwareRenderer::render results after dispatching PointerPressed return a dirty area that's 464x100, which is the button area. This is what I expect. However, the SoftwareRenderer::render results after dispatching PointerReleased and PointerExited events always returns a dirty area representing the full screen, 480x320.

Video of this in action is posted here: https://youtu.be/Q77ma-mtZVA?si=XU-Lybd8xA-5LFRA

Reproducible Code (if applicable)

Touch event/repaint loop:

let window = MinimalSoftwareWindow::new(RepaintBufferType::ReusedBuffer);

// ... other code ...

loop {
    slint::platform::update_timers_and_animations();
    let mut dirty_region = PhysicalRegion::default();
    let dirty = window.draw_if_needed(|renderer| {
        dirty_region = renderer.render(
            framebuf.as_mut_slice(),
            DISPLAY_LAYOUT.logical_width() as usize,
        );
    });
    if dirty {
        lcd.repaint_region(framebuf.as_ref(), &dirty_region.into()).await;
    }

    let wait_ms = if window.has_active_animations() {
        0
    } else {
        slint::platform::duration_until_next_timer_update()
            .map(|d| d.as_millis())
            .unwrap_or(3600)
    };

    match select(TOUCH_EVENTS.receive(), Timer::after_millis(wait_ms as u64)).await {
        Either::First(touch_event) => {
            let window_event: WindowEvent = touch_event.into();
            let released = matches!(window_event, WindowEvent::PointerReleased { .. });
            info!("Dispatching {:?}", window_event);
            window.dispatch_event(window_event);
            if released {
                info!("Dispatching {:?}", WindowEvent::PointerExited);
                window.dispatch_event(WindowEvent::PointerExited);
            }
        }
        Either::Second(_) => {}
    }
}

Slint UI code:

import { Button, VerticalBox, AboutSlint } from "std-widgets.slint";

export component AppWindow inherits Window {
    width: 480px;
    height: 320px;
    default-font-size: 64px;
    property <int> count: 0;
    VerticalBox {
        Button {
            height: 100px;
            text: count;
            clicked => {
                count += 1;
            }
        }
        AboutSlint { }
     }
}

Environment Details

• Slint Version: 1.9.2
• Platform/OS: xtensa-esp32s3-none-elf (embedded mcu)
• Programming Language: Rust
• Backend/Renderer: Software

Product Impact

What are you building with Slint?

An open source nitrox analyzer for scuba diving. Will be publishing to Github, but right now it's in its infancy.

How critical is this issue for your product (e.g., blocker, inconvenience)? This helps us prioritize the issue effectively.

It's a performance-related inconvenience. Full screen repaints take ~100ms, so tapping in quick succession can be noticeably laggy.

[tronical]

@ogoffart and I suspect that this is due to an if() inside the Button implementation, which - upon condition change - ends up destroying a sub-tree of items and causing a full refresh :(.

[tronical]

Related test that covers this:

slint/api/rs/slint/tests/partial_renderer.rs

Line 316 in 3cb4bd1

// Currently we redraw when a condition becomes false because we don't track the position otherwise

[ogoffart]

As @tronical mentioned, the Button element has an if that becomes false if the window looses focus (happens with the MouseExit event)

slint/internal/compiler/widgets/fluent/button.slint

Line 121 in edbcab7

if (root.has-focus && root.enabled) : FocusBorder {

And this cause the free_graphics_resources to force a full rendering.

slint/internal/core/item_rendering.rs

Lines 1099 to 1101 in 3cb4bd1

	// We don't have a way to determine the screen region of the delete items, what's in the cache is relative. So
	// as a last resort, refresh everything.
	self.force_screen_refresh.set(true)

Ideally, if we would cache the absolute rectangle, we'd be able to only mark the region previously covered by these items as dirty.