Bug: Window grows infinitely

[ecton]

There is an edge condition that @dnaka91 encountered in the released version of Gooey. My summary from Discord:

What you're seeing is that the measured size is always growing each time the window redraws, and there is logic to try to automatically resize the window to fit the minimum size of the content. You can imagine that if there's a bug in calculating the size how it can get into a loop.

He is running Cinnamon with some sort of unique fractional scaling mode. If anyone else encounters this bug, providing an example (or saying which example reproduces it) and what DPI scale your display is would be incredibly helpful. To see what DPI scale your display has, the easiest way is to run this Gooey snippet:

use gooey::widgets::Canvas;
use gooey::Run;
use kludgine::figures::units::Px;
use kludgine::text::Text;
use kludgine::Color;

fn main() -> gooey::Result<()> {
    Canvas::new(move |context| {
        let scale = context.gfx.scale();
        context
            .gfx
            .draw_text(Text::<Px>::new(&format!("{scale}"), Color::RED));
    })
    .run()
}

[dnaka91]

Maybe this has to do with the theme example specifically. I ran other examples later on and noticed that they don't resize themselves endlessly.

Also, when I resized the examples (like checkbox) it works fine until I start making it smaller than the widget inside.

As soon as I hit some breakpoint it seems to grow vertically endlessly. But not at all spots. Once I hit some threshold where it wraps the checkbox label and stops until I further reduce the window size and hit the same issue.

It feels like the window is fighting with the active drag by the cursor in this case, or doesn't properly detect that it needs to further wrap the label to fit the widget into the new window size.

[dnaka91]

Another thing to note is the scaling factor. It's printed as the first message in the examples and surprisingly is never 1.0 or 2.0, which I would expect when switching my window scaling to 100% or 200%.

Ran the snippet as well to give you more info on the scaling details.

• 100%
  • scale factor: 1.6666666666666667
  • gfx scale: 5/3
• 150% (my default)
  • scale factor: 2.1666666666666665
  • gfx scale: 13/6
• 200%
  • scale factor: 1.6666666666666667
  • gfx scale: 5/3

In case this has any importance, my X11 reports a normal 2160p resolution in 100% and 200% but in 150% it reports 2880p because it sets it to a higher resolution and then scales it down to the physical monitor size to achieve the fractional scaling.

[ecton]

Could you try out v0.1.3? It contains a fix for a situation where I ran into this as well, and I applied the same fix across multiple widgets.

Even if this is fixed, I want to add some logic to prevent it from happening in the future.

[dnaka91]

The window stopped resizing indefinitely with the latest changes.

However, it seems there are still some problems around the breakpoint of text or text wrapping that cause the window to suddenly increase in vertical size. Especially when draggin the window to a small horizontal size slowly, it hits some spot where it tries to resize vertically too much.

[ecton]

Yeah, that's really the crux of the issue with my attempt at being clever here to try to prevent from obscuring content by making it too small. Ultimately at the point of deciding to try to resize the window, all I know is that we asked the root widget to fit within the window's bounds, and it didn't. We know the size that the root widget measured given the current window size, so we attempt to resize the window to that new size.

However, widgets that can wrap can potentially cause some strangeness here as you've pointed out. I think I'll just remove this feature.

[dnaka91]

Just wanted to mention that I tried it out after the latest commits and now doesn't do any vertical window growth anymore. Thanks for the quick adjustments and great project overall 🚀