Image element blocks resizing

[jmEvoqua]

Bug Description

During refactoring I noticed that an image element blocks the resizing(stretching) in a layout. If I replace the image with an rectangle of the same size the resizing works as expected.

I expected a fixed sized image element to behave the same as a fixed sized rectangle:

What makes it even worse is that when the image is conditional, it works as expected. This makes it very hard to reason about the layout system.

if true: Image {

Reproducible Code (if applicable)

component Main inherits Window {

    HorizontalLayout {

        Rectangle {
            background: green;
        }

        Rectangle {
            background: red;

            Image {
                source: @image-url("https://slint.dev/logo/slint-logo-full-light.svg");
                colorize: white;
                width: 50px;
                height: 50px;
                
            }
        }
    }
}

Environment Details

• Slint Version: 1.8.0
• Platform/OS: Linux
• Programming Language: Rust
• Backend/Renderer:

Product Impact

This sort of bugs makes it hard to understand the (not so intuitive) layout system and requires additional time to find workarounds. The initial fast development speed is slowed down drastically when something odd in the layout happens.

[tronical]

I dug a little further and found out what the difference is between using an image or a plain rectangle: An Image element always has its preferred size set to the natural size of the source. So if you have say an Image { source: @image-url("foo.png"); } where foo.png has a width of say 1000px, then the Image will have a preferred width of 1000px - in an attempt to express that the desired view is to show it unscaled.

So this is "reproducible" without an image:

component Main inherits Window {

    HorizontalLayout {

        Rectangle {
            background: green;
        }

        Rectangle {
            background: red;

            Rectangle {
                background: blue;
                width: 50px;
                height: 50px;
                preferred-width: 165px;
                preferred-height: 66px;
            }
        }
    }
}

(This is not a final statement of resolution, just posting my results of investigating this :)

[tronical]

After playing a bit more with it, so this what I think is happening:

The available width of the Window, that HorizontalLayout distributes, typically exceeds the sum of the minimum widths, so there's "extra" to distribute. The preferred-width of the green rectangle is zero, and the preferred width of the red rectangle is the max of 0 and the preferred width of the blue rectangle (or image). That's why the overall red rectangle starts with a width of 165px and the rest is given to the green rectangle, as that one "doesn't care".

@jmEvoqua I think the answer to this original question then is: The image expresses a preferred size, as opposed to the "empty" rectangle, and the layout takes that into account. All in what I think is an attempt to avoid scaling the image unless necessary.

[jmEvoqua]

Thanks for the help. This explains why the image has a starting width. But there is still one difference.

The red rectangle with the image does not resize at all (not using more of the available space).

The red rectangle in your example with the other rectangle does resize. It will be larger than the green Rectangle, but that is expected.

[tronical]

That's right. I think that's because the plain Rectangle has a horizontal-stretch: 1; while the Image has horizontal-stretch: 0;. In the docs ("Stretch Algorithm") this is explained like this:

The elements that have a default content size usually defaults to 0 while elements that default to the size of their parents defaults to 1.

[jmEvoqua]

Thanks for the explanation :)

I understand it now.

[tronical]

I think our initial reaction yesterday was to mark this as a bug. With this analysis, I think we need to improve on the documentation.

The central question was why the Image behaves differently than the Rectangle.

While the underlying information may be spread out in the docs, what's missing is a more element centric view on the behaviour of the layouts.

[tronical]

On second thought: Perhaps it's a bug that the Image's preferred size is used and propagated when the Image can never obtain that size because it's already fixed.

[tronical]

I discussed with Olivier and we agreed that if an element has a fixed width/height, it doesn't make sense to maintain the preferred size. We already fix up min/max width, so we should also do that for preferred width/height if a fixed width is set.