fix mac frame-rate regression for non-threaded GPU compositing
This change looks weird - sorry about that. On Mac, setNeedsDisplay-driven drawRect calls appear to be implemented with a software timer that is slightly slower than vsync. So in order to render aligned with Vsync we have to either use CVDisplayLink or call CGLFlushDrawable immediately when new frames arrive at the browser RWHVMac. CVDisplayLink adds a frame of latency, so we don't want to use that for rendering. So, we call CGLFlushDrawable immediately. Calling CGLFlushDrawable is fine except when the window becomes non-visible, during which undocumented behavior kicks in: CGLFlushDrawable returns immediately, no longer throttled to vsync. So, we have the unfortunate task of manually throttling CGLFlushDrawable so that chrome doesn't spin while the window is hidden. The implementation of manual throttling is to use CVDisplayLink to compute vsync frame counts, and compare that to the flush (swap) counts. If the swap count gets more than frames ahead of vsync, we sleep for 1 frame interval to simulate blocking on vsync. NOTE: this code path is only for the non-threaded accelerated compositing path. It will not be triggered for the threaded compositing path because we won't render frames at faster than vsync unless there's a bug in the compositor thread scheduling logic. BUG=139416 Review URL: https://chromiumcodereview.appspot.com/10828104 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@150056 0039d316-1c4b-4281-b951-d872f2087c98
Showing
Please register or sign in to comment