The Finder’s GUI tax can be very expensive • Hacker News Board

Re: The Finder’s GUI tax can be very expensive

#121

Post by pvg » Sat, Dec 10, 2016, 2:09 PM UTC

espadrine wrote: post #120

pvg wrote: post #111

Earlier quoted context omitted.

By that (deeply silly) logic, 'having a GUI' is 'deliberate idle time'.

No. You'll notice that your browser doesn't sequentially wait for each character to show up on the screen before rendering the next character. The obvious thing to have done would be to have a single progress bar for all decompression operations requested in a single UI action. Darwin has had a process scheduler for some time now; they can be expected to make good use of it. It is infuriating to be waiting for animat…

Again, this has absolutely nothing to do with the original and inaccurate idea that Archive Utility waits around doing nothing on purpose to give you the impression it's doing something while it's doing nothing. It just means AU is implemented in a way that is slow and inefficient. Which is what I said so hey, we agree!

Re: The Finder’s GUI tax can be very expensive

#122

Post by jessaustin » Sat, Dec 10, 2016, 3:10 PM UTC

egeozcan wrote: post #87

jessaustin wrote: post #62

Earlier quoted context omitted.

So just pop a click-anywhere "Saved!" notification.

Then users will keep clicking on save until that notification comes, when your save takes just a bit longer than usual.

By hypothesis (see https://news.ycombinator.com/item?id=13135385), the operation is effectively instant. If it weren't, a UI on its own thread could notice that and act accordingly.

Re: The Finder’s GUI tax can be very expensive

#123

Post by thaumasiotes » Sat, Dec 10, 2016, 5:22 PM UTC

majewsky wrote: post #101

thaumasiotes wrote: post #46

Earlier quoted context omitted.

Maybe so, but, as pointed out elsewhere in the thread, printing to stdout is much, much, much, much slower than printing to a file. The fact that stdout is a file descriptor can only explain a vanishingly small quantity of the time cost of using it.

> printing to stdout is much, much, much, much slower than printing to a file False dichotomy. stdout can very well be a file. What you mean is that printing to a terminal is slower than to a file.

True enough.

Re: The Finder’s GUI tax can be very expensive

#124

Post by xsmasher » Sat, Dec 10, 2016, 7:36 PM UTC

vortico wrote: post #34

This will be sort of bluntly stated, but I challenge anyone to show me an example of where animation is a usability improvement over no animation at all. I understand how it may be visually pleasing, but I work on computers, not enjoy it as an art form. I do some UI design too and don't remember the last time I added animation. Can anyone find an exception?

Many animations are simply stylistic, but others convey information.

Any animation that gives you "almost there" information about a gesture; fro example, holding your finger on the screen in Minecraft PE starts an animated circle. When the circle completes, the action is complete. It provides extra information.

Ditto for the "swipe right to delete" animations in iOS mail; the animation lets you know which side of the "show options vs delete" wall you're on, and how close to the edge.

Re: The Finder’s GUI tax can be very expensive

#125

Post by appleflaxen » Sun, Dec 11, 2016, 4:06 AM UTC

vortico wrote: post #34

This will be sort of bluntly stated, but I challenge anyone to show me an example of where animation is a usability improvement over no animation at all. I understand how it may be visually pleasing, but I work on computers, not enjoy it as an art form. I do some UI design too and don't remember the last time I added animation. Can anyone find an exception?

the rotation animation when turning your phone to landscape mode.