4 ms·
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
by espadrine 10y ago
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).
- pvg 10y agoNone of these are deliberate idling to give the impression of work which is what the original comment was about.
- coldtea 10y agoHuh? ALL of these are deliberate idle time (idle as in "not spend in actually decompressing) to give the impression of work ...
- pvg 10y agoBy that (deeply silly) logic, 'having a GUI' is 'deliberate idle time'.
- espadrine 10y agoNo. 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.
- pvg 10y agoAgain, 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!