Make RenderWidget send UpdateRect after auto-resize.

Make RenderWidget send UpdateRect after auto-resize.

This sets a flag in didAutoResize() that
didCompleteSwapBuffers() inspects when deciding whether to
send an UpdateRect message or not.  Without this, extension
bubbles aren't getting resized correctly when using the
threaded compositor.

BUG=120247
TEST=manual: "Google Calendar (by Google)" and "Google +1 Button" extensions' bubbles resize to fit their content on Chrome OS


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=137073

[levin, 2012-05-14 23:52:32]

On 2012/05/14 23:40:47, Daniel Erat wrote:

Why is this the right fix? (What is going wrong in the code that this fixes? How
do you know that didCompleteSwapBuffers will be called?)

Normally this would be called done in
http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/...
which is called from
http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/...

[Daniel Erat, 2012-05-15 00:00:16]

On 2012/05/14 23:52:32, levin wrote:
> On 2012/05/14 23:40:47, Daniel Erat wrote:
> 
> Why is this the right fix? (What is going wrong in the code that this fixes?
How
> do you know that didCompleteSwapBuffers will be called?)
> 
> Normally this would be called done in
>
http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/...
> which is called from
>
http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/...

(discussed a bit over IM, but I think that the

  WebViewImpl::sendResizeEventAndRepaint()->
  RenderWidget::didInvalidateRect()->
  RW::InvalidationCallback()->
  RW::DoDeferredUpdateAndSendInputAck()

path isn't used in the accelerated-compositing case; sendResizeEventAndRepaint()
calls updateLayerTreeViewport() instead of didInvalidateRect())

[Andrei, 2012-05-15 00:00:34]

lgtm

[piman, 2012-05-15 00:07:43]

LGTM + 1 minor thing.

https://chromiumcodereview.appspot.com/10399020/diff/1/content/renderer/rende...
File content/renderer/render_widget.cc (right):

https://chromiumcodereview.appspot.com/10399020/diff/1/content/renderer/rende...
content/renderer/render_widget.cc:920: next_paint_flags_ = 0;
I would reset need_update_rect_for_auto_resize_ here so that we don't keep a
stale state when switching from non-ac to ac.

[levin, 2012-05-15 00:12:17]

On 2012/05/14 23:52:32, levin wrote:
> On 2012/05/14 23:40:47, Daniel Erat wrote:
> 
> Why is this the right fix? (What is going wrong in the code that this fixes?
How
> do you know that didCompleteSwapBuffers will be called?)
> 
> Normally this would be called done in
>
http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/...
> which is called from
>
http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/...

I see this was explained in the bug. Thanks!

[Daniel Erat, 2012-05-15 00:29:27]

https://chromiumcodereview.appspot.com/10399020/diff/1/content/renderer/rende...
File content/renderer/render_widget.cc (right):

https://chromiumcodereview.appspot.com/10399020/diff/1/content/renderer/rende...
content/renderer/render_widget.cc:920: next_paint_flags_ = 0;
On 2012/05/15 00:07:43, piman wrote:
> I would reset need_update_rect_for_auto_resize_ here so that we don't keep a
> stale state when switching from non-ac to ac.

Whoops, nice catch (levin@ pointed this out too).  Done.

[piman, 2012-05-15 00:44:26]

lgtm

[commit-bot: I haz the power, 2012-05-15 02:15:31]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/derat@chromium.org/10399020/9001

[commit-bot: I haz the power, 2012-05-15 03:43:27]

Change committed as 137073