diff options
| author | ccameron <ccameron@chromium.org> | 2015-03-12 15:29:11 -0700 |
|---|---|---|
| committer | Commit bot <commit-bot@chromium.org> | 2015-03-12 22:30:26 +0000 |
| commit | 398ff0bdf8f314a6f98d8d7ea348ea89d44aa7b3 (patch) | |
| tree | c782a97df8da1fe36e2e623131b5a873aea18deb /components/components.gyp | |
| parent | 37f9cad0a5a945bda2d4ebfe2217db7711572718 (diff) | |
| download | chromium_src-398ff0bdf8f314a6f98d8d7ea348ea89d44aa7b3.zip chromium_src-398ff0bdf8f314a6f98d8d7ea348ea89d44aa7b3.tar.gz chromium_src-398ff0bdf8f314a6f98d8d7ea348ea89d44aa7b3.tar.bz2 | |
Mac: Don't force an immediate draw during tab-switch
I introduced this behavior in
https://codereview.chromium.org/810333005
with the reasoning that by forcing an immediate draw, we will tab-switch
faster.
That reasoning is still true, but after cleaning up a number of other
sources of slow tab-switch, I found that, while this un-blocks
tab-switch faster, the window system doesn't like it when these draws
are forced. In particular, it will often just flash a blank frame for
the remote CALayer.
If we were okay with a flash of a blank frame, then we won't do the
stall waiting for a frame to begin with.
BUG=463988
Review URL: https://codereview.chromium.org/1004513003
Cr-Commit-Position: refs/heads/master@{#320392}
Diffstat (limited to 'components/components.gyp')
0 files changed, 0 insertions, 0 deletions