| commit | a1b62c42ab4a27a50107b0abdacb0d4b18b0b6a2 | |
| author | shess <shess@chromium.org> | |
| Sat, 6 Jun 2015 18:39:55 +0000 (6 11:39 -0700) | ||
| committer | Commit bot <commit-bot@chromium.org> | |
| Sat, 6 Jun 2015 18:40:26 +0000 (6 18:40 +0000) | ||
| tree | c92179d2739ffa29b875abd8a8e5e1ab5ce5ca94 | treesnapshot (tar.gz zip) |
| parent | b95bbfb9b48f40a15e0ba051a41b6250dfd33698 | commitdiff |
[OSX] Revert deferred-window change for FramedBrowserWindow.
The change from defer:YES to defer:NO appears to have caused a perf
regression in startup.warm.blank_page . My best hypothesis is that
Chromium doesn't provide all info at creation time, instead it sets size
and contents and the like piecemeal. With defer:YES, these things
short-circuit operations which need to touch the backing store, while
with defer:NO they actually make changes.
This reverts part of:
https://chromium.googlesource.com/chromium/src/+/fa89814df86cd44a
BUG=496116
Review URL: https://codereview.chromium.org/1152943004
Cr-Commit-Position: refs/heads/master@{#333218}
The change from defer:YES to defer:NO appears to have caused a perf
regression in startup.warm.blank_page . My best hypothesis is that
Chromium doesn't provide all info at creation time, instead it sets size
and contents and the like piecemeal. With defer:YES, these things
short-circuit operations which need to touch the backing store, while
with defer:NO they actually make changes.
This reverts part of:
https://chromium.googlesource.com/chromium/src/+/fa89814df86cd44a
BUG=496116
Review URL: https://codereview.chromium.org/1152943004
Cr-Commit-Position: refs/heads/master@{#333218}
| chrome/browser/ui/cocoa/framed_browser_window.mm | diffblobblamehistory |