Live data from Hacker News

The Finder’s GUI tax can be very expensive

robservatory.com

111–120 of 125 posts

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

#111
post #100

Earlier quoted context omitted.

None of these are deliberate idling to give the impression of work which is what the original comment was about.

Huh? ALL of these are deliberate idle time (idle as in "not spend in actually decompressing) to give the impression of work ...

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

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

#112
post #106

Earlier quoted context omitted.

The N64 in turn took the start screen thing from the Super Famicom and Famicom before it. I assume title screens are just that: title screens, and the developers want to show off. Maybe it's a legacy of arcade machines, though.

PC games never had a title screens, until the first bad console ports around 2003 came along. Instead of a title screen, PC games used to go to the main menu directly. Even today, some console games like GTA V don't have a title screen, but many smaller games feature a useless title screen.

What about DOOM (1992)? That had a title screen of sorts.

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

#113
post #106

Earlier quoted context omitted.

The N64 in turn took the start screen thing from the Super Famicom and Famicom before it. I assume title screens are just that: title screens, and the developers want to show off. Maybe it's a legacy of arcade machines, though.

PC games never had a title screens, until the first bad console ports around 2003 came along. Instead of a title screen, PC games used to go to the main menu directly. Even today, some console games like GTA V don't have a title screen, but many smaller games feature a useless title screen.

Tons of PC games have had title screens going way back. Ultima IV (1985) and Commander Keen (1990) spring to mind.

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

#114

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.

>Microsoft requires a button press every x seconds What is the rationale behind such a requirement? >if the game takes too long to load before the menu appears, pressing A will circumvent that requirement. Does this mean those screens/videos that get displayed after the game starts and before the menu appears are required by Microsoft to be skippable? If that's the case then it's good UX design in my opinion. I think…

It doesn't mean they have to be skippable, just that they can't drag on too long.

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

#115

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.

>Microsoft requires a button press every x seconds What is the rationale behind such a requirement? >if the game takes too long to load before the menu appears, pressing A will circumvent that requirement. Does this mean those screens/videos that get displayed after the game starts and before the menu appears are required by Microsoft to be skippable? If that's the case then it's good UX design in my opinion. I think…

Presumably so they can see how long it takes to handle input events, because that's a good proxy for whether the application is responsive or not. What they don't want is the game freezing. But that's harder to measure directly.

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

#116
post #35

Earlier quoted context omitted.

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.

Maybe it's a minor security feature. Unzipping something in the background might be something they want to always call attention to.

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

#117
post #58

I've encountered this in command-line programs as well. Print statements take a non-zero amount of time and depending on the language, can be quite slow, so for an otherwise-fast operation in a loop, if it prints a line every time then it can contribute significantly to the overall speed of the program. Removing the print statements in some cases can speed up the code by an order of magnitude.

Avoid verbose flags on tar.

rsync as well, especially the progress bars.

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

#118
post #106

Earlier quoted context omitted.

The N64 in turn took the start screen thing from the Super Famicom and Famicom before it. I assume title screens are just that: title screens, and the developers want to show off. Maybe it's a legacy of arcade machines, though.

PC games never had a title screens, until the first bad console ports around 2003 came along. Instead of a title screen, PC games used to go to the main menu directly. Even today, some console games like GTA V don't have a title screen, but many smaller games feature a useless title screen.

My copy of Alley Cat from 1983 disagrees with you.

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

#120
post #111

Earlier quoted context omitted.

Huh? ALL of these are deliberate idle time (idle as in "not spend in actually decompressing) to give the impression of work ...

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 animations to end for literally 12 seconds.

Post reply on HN