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.
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.
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.
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.
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 :)
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.
Is there an animated example of resizing done right?
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.
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..
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.
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.
Ah.
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.
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.
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 :)
I remember using Netscape Navigator 4.x on X11, where it had the most awful window resizing performance imaginable.
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.