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

101–110 of 125 posts

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

#101

Post by majewsky »

thaumasiotes wrote: post #46
dijit wrote: post #31

Earlier quoted context omitted.

quiet reminder that writing to file descriptors is blocking. STDERR and STDOUT are file descriptors.

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.

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

#102

Post by arghIdontwantto »

matheusmoreira wrote: post #65
TazeTSchnitzel wrote: post #17

Earlier quoted context omitted.

This reminds me of how some PlayStation game's developers complained that they were required by Sony to add a false multi-second delay to their game's save routine, so the user would have enough time to read the mandatory warning not to turn off the console. Their game in fact saved so quickly there needn't be a warning at all.

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…

Can only speak for PlayStation 2 games (I also worked on PS3 and XBox 360 but didn't handle that part). Sony's Technical Requirements were a pain. We had to build a freaking complicated State machine to handle all save scenarios (PS2 still used those external things to save games, you had to handle the user taking it out midsave, put back, etc). We had a game rejected for having a SINGLE space between PlayStation and that registered trademark symbol.

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

#103

Post by whywhywhywhy »

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.

quicksave/quickload encourages bad game design. Look at games with save anywhere abilities that include elements of chance like Skyrim and Fallout. So you are able to pickpocket and use charm in these games but because you can save anywhere does anyone ever live with the chance these things fail?

Of course not they just try>reload>try>reload>try>succeed. Making that whole skill set pointless and the mechanic pointless

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

#105

Post by TazeTSchnitzel »

frik wrote: post #78
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.

N64 had press Start to start, years before XBox was even a thing. And yes, many/most PC ports are of very low quality. Gone are the days of PC-first Triple-A games with forgotten features like Quick-save/load, LAN-multiplayer, Map-editor, official Mod-support. These days, these ports feel like they started porting two months before release, done by two coders. All these console-ish things like messages "don't turn of…

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.

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

#106

Post by frik »

TazeTSchnitzel wrote: post #105
frik wrote: post #78

Earlier quoted context omitted.

N64 had press Start to start, years before XBox was even a thing. And yes, many/most PC ports are of very low quality. Gone are the days of PC-first Triple-A games with forgotten features like Quick-save/load, LAN-multiplayer, Map-editor, official Mod-support. These days, these ports feel like they started porting two months before release, done by two coders. All these console-ish things like messages "don't turn of…

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.

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

#108

Post by frik »

whywhywhywhy wrote: post #103
frik wrote: post #76

Earlier quoted context omitted.

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.

quicksave/quickload encourages bad game design. Look at games with save anywhere abilities that include elements of chance like Skyrim and Fallout. So you are able to pickpocket and use charm in these games but because you can save anywhere does anyone ever live with the chance these things fail? Of course not they just try>reload>try>reload>try>succeed. Making that whole skill set pointless and the mechanic pointles…

not offering quick-save is bad game design. a game should be about fun. nowadays it's often more about work (boring grinding gameplay, save-points were you have to play the same passage several times again... oh what great game design - not). with current gen-consoles there is no single technical reason not offer quick-save & load. and for driving games, the quick-playback feature introduced by Codemaster in GRID should nowadays be common, but sadly is not.

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

#109

Post by coldtea »

pvg wrote: post #92
coldtea wrote: post #83

Earlier quoted context omitted.

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...

It isn't because they don't do anywhere close to the same thing. Watch the video: http://robservatory.com/postimages/unzipping/finder_v_termin... Where do you think the people who wrote the thing that happens on the left inserted a gratuitous sleep?

obviously when they show the notification for each completed unit?

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

#110

Post by coldtea »

pvg wrote: post #100
espadrine wrote: post #93

Earlier quoted context omitted.

For each file, a split second to animate the apparition of the window (or the increase of the existing window), another split second to show the empty progress bar, a millisecond to fork the decompression process, a couple of frames at 60 Hz to animate it being filled, and another split second to animate the disappearance of the window (or the decrease of the existing window).

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 ...
Post reply on HN