diff options
author | jamesr@chromium.org <jamesr@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-04-17 01:46:31 +0000 |
---|---|---|
committer | jamesr@chromium.org <jamesr@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-04-17 01:46:31 +0000 |
commit | 0bc1f571fa6242ec413b70d2a10cbbfd07fedd63 (patch) | |
tree | 6762939d087045eb565528ba4442d66193c66fee /webkit/webkit.gyp | |
parent | ce6206d90233a1bc0f732242c5afe70ff52dc448 (diff) | |
download | chromium_src-0bc1f571fa6242ec413b70d2a10cbbfd07fedd63.zip chromium_src-0bc1f571fa6242ec413b70d2a10cbbfd07fedd63.tar.gz chromium_src-0bc1f571fa6242ec413b70d2a10cbbfd07fedd63.tar.bz2 |
Avoid sending empty OnRepaint msgs and propagate window damage correctly
This fixes two issues related to OnRepaint (window damage) messages:
1.) In the case of a renderer-resized widget, the browser's information about
the size of the widget could be out of date. If the browser widget was asked to
paint in compositing mode before it received the proper size it could send a
ViewMsg_OnRepaint with 0x0 size and then set repaint_ack_pending_, expecting the
renderer to reply. The renderer wasn't actually replying with a frame since
damaging a 0x0 rect doesn't actually require painting anything. This suppresses
sending the OnRepaint message if the browser's size is 0x0. Either the size will
at some point become 0x0, triggering a repaint, or the user will never see it.
2.) In compositing mode on the renderer side we weren't plumbing the OnRepaint
window damage rect properly in to the compositor. Thus the compositor could end
up not producing a frame after receiving an OnRepaint message, confusing the
browser rate limiting logic greatly.
BUG=230766
Review URL: https://codereview.chromium.org/13926009
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@194510 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'webkit/webkit.gyp')
0 files changed, 0 insertions, 0 deletions