Hacker News Reader

Comment by mschaef | Hacker News Reader

This reminds me that as part of the Windows95 development effort, Microsoft disabled per-second updates of the taskbar clock to improve performance. Raymond Chen wrote a bit on it back in 2003:

https://blogs.msdn.microsoft.com/oldnewthing/20031010-00/?p=...

View on HN

I've made clocks before, and tried to either have them woken up when it's (almost) time to update - or have them sleep long enough that it'll be (almost) time to update. Only seems polite.

On the other hand, iPhone's "Clock" app has an icon that shows the correct time with a super smooth seconds indicator. Which doesn't drain the battery.

How fast does it run on 1995 hardware though?

Pretty sure any sane software implementation of a simple seconds pointer would easily update faster than 1 Hz while using little to negligible CPU time in a Desktop processor from the 90's and onwards.

The Windows 1.0 clock (1988) had a 1Hz second sweep hand that ran on a 4.77MHz 8088. It's really just a couple clipped line segments each second.

http://variableghz.com/wp-content/uploads/2012/12/windows-1....

Yes, that was the point I was making. This is something computationally trivial as long as the code is written appropriately.

Keep in mind though, that the performance optimization the Windows article talks about is how to reduce the working set in memory more than the CPU consumption.

It probably does drain the battery if you leave it on the screen for a while. They can get away with it because people usually aren't looking at their app icons for extended periods of time.

The Windows 95 optimization related to the blinking clock making it difficult to page code out... which was very important on systems at the minimum 4MB RAM required by Windows 95.

I suspect that iPhone's "Clock" app would have difficulties both with smoothness and battery life if constrained to 4MB of RAM and paging...

Reply on news.ycombinator.com