aw: Add and use DrawGL kModeSync

aw: Add and use DrawGL kModeSync

We need to support this new hidden api to avoid onDraw getting ahead of
DrawGL. Without this, onDraw can finish producing frame n+1 before DrawGL
consumes frame n, in which case DrawGL skips a frame.

Also make AwDrawGLInfo future proof.

BUG=397358
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=285712

[boliu, 2014-07-24 23:45:26]

work in progress, seems to work though

[boliu, 2014-07-25 00:10:50]

Doesn't look too bad.

hush for everything, and benm to look at draw_gl.h that's an attempt to make
this future proof

[boliu, 2014-07-25 16:06:54]

ping for ben to review draw_gl.h, want to get this in today if possible

[hush (inactive), 2014-07-25 18:08:07]

https://codereview.chromium.org/414163002/diff/20001/android_webview/native/a...
File android_webview/native/aw_contents.cc (right):

https://codereview.chromium.org/414163002/diff/20001/android_webview/native/a...
android_webview/native/aw_contents.cc:347: hardware_renderer_->CommitFrame();
CommitFrame will just copy the child draw result (framedata) to the parent and
recreate the delegated layer in parent if needed.
Then in the next kModeDraw, parent compositor will draw the frame, issue GL
commands, etc.

Do I understand it correctly?

Is the following sequence of events guaranteed?
ondraw --> kModeSync --> kModeDraw

And you always have a 1 to 1 correspondence between kModeSync and kModeDraw,
right?

https://codereview.chromium.org/414163002/diff/20001/android_webview/public/b...
File android_webview/public/browser/draw_gl.h (right):

https://codereview.chromium.org/414163002/diff/20001/android_webview/public/b...
android_webview/public/browser/draw_gl.h:16: int version;  // The AwDrawGLInfo
this struct was built with.
where is the version set? I think you need to do that in frameworks/webview?

[boliu, 2014-07-25 18:11:02]

https://codereview.chromium.org/414163002/diff/20001/android_webview/native/a...
File android_webview/native/aw_contents.cc (right):

https://codereview.chromium.org/414163002/diff/20001/android_webview/native/a...
android_webview/native/aw_contents.cc:347: hardware_renderer_->CommitFrame();
On 2014/07/25 18:08:07, hush wrote:
> CommitFrame will just copy the child draw result (framedata) to the parent and
> recreate the delegated layer in parent if needed.
> Then in the next kModeDraw, parent compositor will draw the frame, issue GL
> commands, etc.
> 
> Do I understand it correctly?
> 
> Is the following sequence of events guaranteed?
> ondraw --> kModeSync --> kModeDraw

Everything above here is correct.

> 
> And you always have a 1 to 1 correspondence between kModeSync and kModeDraw,
> right?

No. kModeDraw can happen more times compared to kModeSync, it will just keep
drawing the same frame. onDraw and kModeSync are 1-to-1 though.

https://codereview.chromium.org/414163002/diff/20001/android_webview/public/b...
File android_webview/public/browser/draw_gl.h (right):

https://codereview.chromium.org/414163002/diff/20001/android_webview/public/b...
android_webview/public/browser/draw_gl.h:16: int version;  // The AwDrawGLInfo
this struct was built with.
On 2014/07/25 18:08:07, hush wrote:
> where is the version set? I think you need to do that in frameworks/webview?

Yes

[hush (inactive), 2014-07-25 18:31:00]

https://codereview.chromium.org/414163002/diff/20001/android_webview/native/a...
File android_webview/native/aw_contents.cc (right):

https://codereview.chromium.org/414163002/diff/20001/android_webview/native/a...
android_webview/native/aw_contents.cc:347: hardware_renderer_->CommitFrame();
Okay.
Imagine a scenario where onDraw happens every 16ms, but DrawGL is ridiculously
slow.
Without this change, the new frame data that is produced on UI thread just keeps
getting overwritten by the next onDraw because DrawGL is slow and hasn't
finished the previous frame yet. In this case, DrawGL will draw an old frame.

With this change, the parent compositor will always have the most recent
framedata due to kModeSync, so the parent still drop some frames because UI is
producing frames faster than RT can handle, but will always use the most recent
frame when it draws.

Is that right?
On 2014/07/25 18:11:02, boliu wrote:
> On 2014/07/25 18:08:07, hush wrote:
> > CommitFrame will just copy the child draw result (framedata) to the parent
and
> > recreate the delegated layer in parent if needed.
> > Then in the next kModeDraw, parent compositor will draw the frame, issue GL
> > commands, etc.
> > 
> > Do I understand it correctly?
> > 
> > Is the following sequence of events guaranteed?
> > ondraw --> kModeSync --> kModeDraw
> 
> Everything above here is correct.
> 
> > 
> > And you always have a 1 to 1 correspondence between kModeSync and kModeDraw,
> > right?
> 
> No. kModeDraw can happen more times compared to kModeSync, it will just keep
> drawing the same frame. onDraw and kModeSync are 1-to-1 though.

[boliu, 2014-07-25 18:41:51]

https://codereview.chromium.org/414163002/diff/20001/android_webview/native/a...
File android_webview/native/aw_contents.cc (right):

https://codereview.chromium.org/414163002/diff/20001/android_webview/native/a...
android_webview/native/aw_contents.cc:347: hardware_renderer_->CommitFrame();
On 2014/07/25 18:31:00, hush wrote:
> Okay.
> Imagine a scenario where onDraw happens every 16ms, but DrawGL is ridiculously
> slow.
> Without this change, the new frame data that is produced on UI thread just
keeps
> getting overwritten by the next onDraw because DrawGL is slow and hasn't
> finished the previous frame yet. In this case, DrawGL will draw an old frame.

Yes. But "old frame" isn't a good charaterization. It's a two stage pipeline.
Before this change, we advanced the pipeline in DrawGL. So "old frame" just
means the second stage of the pipeline

> 
> With this change, the parent compositor will always have the most recent
> framedata due to kModeSync, so the parent still drop some frames because UI is
> producing frames faster than RT can handle, but will always use the most
recent
> frame when it draws.

Can't happen. Remember I said onDraw and kModeSync are 1-to-1. Framework will
block the UI thread after onDraw until kModeSync happens.

[benm (inactive), 2014-07-25 18:53:15]

lgtm

[hush (inactive), 2014-07-25 20:35:14]

lgtm

[boliu, 2014-07-25 21:06:08]

The CQ bit was checked by boliu@chromium.org

[commit-bot: I haz the power, 2014-07-25 21:06:45]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/boliu@chromium.org/414163002/20001

[commit-bot: I haz the power, 2014-07-25 22:30:27]

Change committed as 285712