Performance issue - long time to destroy controls + ListView alternative?

[yanshay]

I'm developing on ESP32, and want to develop a control that can scroll through a few hundreds of rectangles with touch-area. Because it is on a small screen I'm developing my own navigation controls.
It uses SwipeGestureHandler, and a few rectangles (for scrollbars) that manipulate the y attribute of a VerticalLayout containing all buttons. I'm also animating the y to get a smooth scroll. And it all works reasonably well.

When loading about 150 items everything works fine. It shows quickly and functions well.
However, when the view is destroyed it takes a few good seconds for it to disappear. This is not something that would work for my application.

• Is that reasonable timing for destroying components (when creating them do

I compared that behavior to ListView and with ListView that slow destroy isn't there.

• Are there any optimizations in ListView? I couldn't find the source for ListView - is it implemented in some special way in Rust?
• Is there a way for me to implement the same optimizations in my code?

When trying to migrate my code to use ListView, I couldn't get things to work.
I couldn't get the viewport-y to be animated for smooth scrolling, I couldn't bind viewport-y to another property - that property changed but the viewport-y didn't, etc.

• Is it possible to fully control ListView scroll positioning including animations?

• If I end up having to use ListView, the scroll-bar there is completely unusable on a small device. It is very narrow, built for a desktop application. Is there a way to at least control its width in anyway? It seems like that's not accessible but maybe there's a way?

[yanshay]

Update: I was able to make an optimization to my code by rendering only the visible elements from the large list based on position and visibility. Because slint is limited in what can be done in expressions/functions I'm limited now to all items in the list being the same size. I think that's a limitation of ListView as well.

But on top of the questions in previous message, is there a way to create components normally and have slint optimize out components that aren't visible? It has all the information (x, y, width, height) and could easily just leave blank spot where a component is not visible and not accessible for interaction, yet it seems like it does create them all. I tried using clip which didn't help. Is there another option to have slint do that optimization?

[ogoffart]

However, when the view is destroyed it takes a few good seconds for it to disappear. This is not something that would work for my application.

This doesn't seem normal. Maybe there is a bug or some way to optimize.

Are there any optimizations in ListView? I couldn't find the source for ListView - is it implemented in some special way in Rust?

The code that instentiate the item in Rust is there:

slint/internal/core/model.rs

Line 965 in a1c2e2f

pub fn ensure_updated_listview(

(Note that if you're using C++, then it is not optimized the same way)

And it is at this point not possible to implement it the same way for a custom ListView.

Is it possible to fully control ListView scroll positioning including animations?

You can work on the viewport-y property.
But the animation is harder.

If I end up having to use ListView, the scroll-bar there is completely unusable on a small device

Right now the material style has the best ListView form embedded.

[yanshay]

The code that instentiate the item in Rust is there:

Is it possible for me, developing not inside Slint, to develop components in Rust as well? The Slint language is pretty limited when more complex coding is required, and only implementing callbacks is more complex. If I could develop rust components that would be great. Is there a demo for something like that?

Right now the material style has the best ListView form embedded.

Is there a different underlying implementation for each style?

This doesn't seem normal. Maybe there is a bug or some way to optimize.

In case it helps, I'm using my own custom button (see code below).

When there are 170 of those, it takes about 4-5 seconds (on esp32s3) to tear down the display. The whole page is under an if condition and when the condition becomes false it takes those 4-5 seconds).

When there are only 7 (which is enough to cover the small screen I'm using), it is immediate. Everything else stays the same, I just create 170 in a VerticalLayout vs 7, using the exact same code.
So I implemented my own code in slint that displays only those 7 and picks them by calculating which 7 need to be visible and positioned where, animation works (though I found serious bugs with animated properties, will file those separately).

export component MyButton {
    in property <string> text;
    in property <length> text-padding;
    in property <bool> enabled: true;
    in property <bool> pushed: false;
    in property <TextHorizontalAlignment> horizontal-alignment: center;
    callback clicked;
    Rectangle {
        background: enabled ? @linear-gradient(20deg, #3559E0 0%, #c2cdf6 100%) : @linear-gradient(20deg, #5C5C5C 0%, #CFCFCF 100%);
        width: root.width;
        height: root.height;
        Text {
            x: text-padding;
            width: parent.width - text-padding * 2;
            horizontal-alignment: root.horizontal-alignment;
            text: root.text;
            font-size: 20px;
            font-weight: 400 + (enabled && area.pressed ? 500 : 0);
            wrap: word-wrap;
            color: enabled ? black : #666666;
        }

        area := TouchArea {
            width: parent.width;
            height: parent.height;
            clicked => {
                if enabled {
                    root.clicked();
                }
            }
        }
    }