News for hackers. Stuff that matters.
Re:The Finder’s GUI tax can be very expensive by espadrine on Friday December 09, 2016 @07:32AM (#13138364)
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).
Re:The Finder’s GUI tax can be very expensive by pvg on Friday December 09, 2016 @09:26AM (#13138887)
None of these are deliberate idling to give the impression of work which is what the original comment was about.
Re:The Finder’s GUI tax can be very expensive by coldtea on Friday December 09, 2016 @12:33PM (#13140152)
Huh? ALL of these are deliberate idle time (idle as in "not spend in actually decompressing) to give the impression of work ...
Re:The Finder’s GUI tax can be very expensive by pvg on Friday December 09, 2016 @12:50PM (#13140306)
By that (deeply silly) logic, 'having a GUI' is 'deliberate idle time'.
Re:The Finder’s GUI tax can be very expensive by espadrine on Saturday December 10, 2016 @01:35AM (#13144401)
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.

Re:The Finder’s GUI tax can be very expensive by pvg on Saturday December 10, 2016 @09:09AM (#13145693)
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!