1. 37
    1. 3

      Is there an animated example of resizing done right?

      1. 7

        The second gif in Tristan’s blog post has 3 instances, two of which don’t have the glitching. Might be worth coming up with more visuals though.

    2. 2

      I’ve had this problem with a terminal app and gtk. SIGWINCH wasn’t sent very often while resizing, which makes smooth resize impossible in TUI..

    3. 2

      How much does it matter? I resize windows, there’s usually a few weird glitches, but as long as it mostly approximates the correct window it seems fine. I don’t like to make excuses for doing the “wrong” thing but I don’t recall anyone ever complaining and I can’t really think of any practical consequences. As soon as I stop resizing, the window has the correct contents.

      1. 16

        The point of the post is to describe a proxy metric for “good GUI frameworks” that’s easy to measure.

        Not being able to smoothly resize windows may not be too big a deal in and of itself. It points to other underlying issues that may end up being a big deal, however.

        1. 1


      2. 6

        It’s a good proxy that is easy to check and use.

        As someone who resizes a lot, I definitely find it important. Jarring or slow resizing has an effect on how much I like an app. For example, I hate Thunderbird for that reason, it’s just terrible at this.

      3. 2

        Did you even read the first part of the article?

        That’s just a proposed alternative to the “green tea test” for Chinese restaurants or the “tamagoyaki test” for sushi restaurants but for GUI frameworks.

      4. 1

        It’s not only a great way to test for “quality” in general, but resizing is a great insight into the attitudes and priorities of a GUI framework. It’s very easy to mess up the combination of flexible layout and nested component hierarchies, particularly when objects can have min/preferred sizes, and scrollbars can come and go. Sometimes you can get yourself into ugly edge cases where user resizes can trigger a scrollbar to appear on a container, which then causes another layout loop inside it because the inner size has changed (thanks to the new scrollbar), and so on and so forth. It can get real ugly :)

    4. 1

      I remember using Netscape Navigator 4.x on X11, where it had the most awful window resizing performance imaginable.

    5. 1

      I looked at this many years ago with KDE in XFree86. I didn’t have enough in-depth knowledge of the various systems involved at the time, but did get as far as seeing what happened if the window was given resize events more often: A feeling of drag on the pointer as dozens or hundreds of window repaints occurred. With fewer events, there was a lag, then a draw - repeated a number of times depending on how slowly the window was resized.

      What surprised me was the amount of context switching going on (measured via /proc IIRC). I didn’t know why the kernel was involved, but I assume it was due to the mouse driver passing events to X. No idea if this affected performance but it was as far as I got with investigating.