Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Finder’s GUI tax can be very expensive

robservatory.com

Post reply on HN
Print view View original

81–90 of 125 posts

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

#81

Post by jamesgeck0 »

chipperyman573 wrote: post #72
matheusmoreira wrote: post #65

Earlier quoted context omitted.

This is really interesting. I read that warning every time I save and I never noticed the delay. For some reason, it doesn't bother me like the archive utility animations. I guess it's because saving the game is a such ritualized action. I wonder what other requirements Sony imposed on developers. Maybe they have their own video game-oriented human interface guidelines. Do you have a source for this information? I fo…

Kind of related, the reason there's a "Press A to play game" on xbox (and a lot of PC ports) is because Microsoft requires a button press every x seconds, and if the game takes too long to load before the menu appears, pressing A will circumvent that requirement.

The other reason behind "Press A to play" is that a console can have several controllers associated with it. Pressing a button at the title lets the game know which controller the user is holding.

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

#82

Post by chipperyman573 »

jamesgeck0 wrote: post #81
chipperyman573 wrote: post #72

Earlier quoted context omitted.

Kind of related, the reason there's a "Press A to play game" on xbox (and a lot of PC ports) is because Microsoft requires a button press every x seconds, and if the game takes too long to load before the menu appears, pressing A will circumvent that requirement.

The other reason behind "Press A to play" is that a console can have several controllers associated with it. Pressing a button at the title lets the game know which controller the user is holding.

Wouldn't it be P1/2/3/4?

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

#83

Post by coldtea »

pvg wrote: post #24
patio11 wrote: post #16

I wonder whether this is not an example of a UI interaction which is slow on purpose, to emphasize how much work the OS is doing for you. TaxAct and TurboTax, for example, both operate on (in the typical case) kilobyte scale data requiring trivial math. They also make both saving the data and calculating taxes take 5+ wall-clock seconds when they actually require milliseconds and nanoseconds respectively. This is lar…

That's highly unlikely. Archive Utility is just slow.

It's highly unlikely that it's 1000 times slower than the command line utility to decompress, with which they share the same libs anyway...

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

#84

Post by sametmax »

frik wrote: post #76
_v7gu wrote: post #73

Earlier quoted context omitted.

I'm never actually sure if I actually saved in the PC port of Valkyria Chronicles. I think we've been trained to wait a while to save since the 8 bit consoles so something feels a bit wrong when things instantly save. Undertale makes amazing use of this, though.

There was a time, when F5 key for Quick-save was common in PC games. Together with Quick-load, it worked very fast, no need for info-screens, it just worked in milli-seconds and allowed gameplay styles completely forgotten or newer experienced by console gamers who are keen to their save-point system.

Baldur's Gate best feature. Allows you to test all variations of the game, every encounter, so much potential, so much possibilty you could just explore, rewind, explore, rewind.

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

#85

Post by chongli »

chipperyman573 wrote: post #82
jamesgeck0 wrote: post #81

Earlier quoted context omitted.

The other reason behind "Press A to play" is that a console can have several controllers associated with it. Pressing a button at the title lets the game know which controller the user is holding.

Wouldn't it be P1/2/3/4?

Only in the case of wired controllers.

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

#86

Post by gpderetta »

frik wrote: post #76
_v7gu wrote: post #73

Earlier quoted context omitted.

I'm never actually sure if I actually saved in the PC port of Valkyria Chronicles. I think we've been trained to wait a while to save since the 8 bit consoles so something feels a bit wrong when things instantly save. Undertale makes amazing use of this, though.

There was a time, when F5 key for Quick-save was common in PC games. Together with Quick-load, it worked very fast, no need for info-screens, it just worked in milli-seconds and allowed gameplay styles completely forgotten or newer experienced by console gamers who are keen to their save-point system.

aka save scumming

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

#87

Post by egeozcan »

jessaustin wrote: post #62
leereeves wrote: post #45

Earlier quoted context omitted.

Then users wonder "Did it actually save?"

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.

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

#88

Post by interpol_p »

patio11 wrote: post #16

I wonder whether this is not an example of a UI interaction which is slow on purpose, to emphasize how much work the OS is doing for you. TaxAct and TurboTax, for example, both operate on (in the typical case) kilobyte scale data requiring trivial math. They also make both saving the data and calculating taxes take 5+ wall-clock seconds when they actually require milliseconds and nanoseconds respectively. This is lar…

I don't think that's the reason. It's more of an edge case due to some minimum animation timing.

If you were expanding 24x 100MB, or 1GB files, the overhead of animation would be much smaller relative to the total time. And it would be quite an informative GUI showing the progress of each file. While the command line version may sit there for a long time before returning to prompt.

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

#89

Post by [deleted] »

userbinator wrote: post #63
fredsir wrote: post #23

Earlier quoted context omitted.

It's not only the communication between the task and the GUI that is slowing things down (if it is at all, which I doubt). Even more, I think, it's the fact that macOS, the OS in question, has some conventions for windows, controls and so forth, one being that it takes X seconds for the window to appear and X seconds for it to disappear. If it was being shown and hidden again as fast as the task starts and finishes,…

If it was being shown and hidden again as fast as the task starts and finishes, it would be just be a flicker on the screen, which would confuse the user. Maybe the really inexperienced users, but it makes sense that something which happens quickly, will mean a window that also appears and disappears quickly. This is why Windows has options to disable animations and other effects, and everything does feel noticeably…

[deleted]

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

#90

Post by kalleboo »

radley wrote: post #35
patio11 wrote: post #16

I wonder whether this is not an example of a UI interaction which is slow on purpose, to emphasize how much work the OS is doing for you. TaxAct and TurboTax, for example, both operate on (in the typical case) kilobyte scale data requiring trivial math. They also make both saving the data and calculating taxes take 5+ wall-clock seconds when they actually require milliseconds and nanoseconds respectively. This is lar…

No, it's about showing it long enough so you know what the dialog is and what it's doing. If a dialog popped up for the brief amount of time it actually takes to unzip, it might freak out users: "huh? WTF was that??"

The Finder already handles this differently for file copy operations - you don't get a file copy progress dialog if it takes less time than you need to react (just an audio confirmation). It seems like Archive Utility didn't get that extra attention though.
Post reply on HN