> I remember the Chrome timer code of years ago was careful to only adjust the interval when needed. From reading other bugs it looks like today's behavior is an accidental regression and will likely be fixed (until the next time it regresses).
Indeed, although it seems the current behavior has been oustanding for some time:
The original justification for lowering the resolution is an interesting read:
At one point during our development, we were about to give up on using the high resolution timers, because they just seemed too scary. But then we discovered something. Using WinDbg to monitor Chrome, we discovered that every major multi-media browser plugin was already using this API. And this included Flash, Windows Media Player, and even QuickTime. Once we discovered this, we stopped worrying about Chrome's use of the API. After all – what percentage of the time is Flash open when your browser is open? I don't have an exact number, but it's a lot. And since this API effects the system globally, most browsers are already running in this mode.[1]
Indeed, although it seems the current behavior has been oustanding for some time:
https://code.google.com/p/chromium/issues/detail?id=153139
The original justification for lowering the resolution is an interesting read:
At one point during our development, we were about to give up on using the high resolution timers, because they just seemed too scary. But then we discovered something. Using WinDbg to monitor Chrome, we discovered that every major multi-media browser plugin was already using this API. And this included Flash, Windows Media Player, and even QuickTime. Once we discovered this, we stopped worrying about Chrome's use of the API. After all – what percentage of the time is Flash open when your browser is open? I don't have an exact number, but it's a lot. And since this API effects the system globally, most browsers are already running in this mode.[1]
[1] http://www.belshe.com/2010/06/04/chrome-cranking-up-the-cloc...