IPC-based sync compositor software draw optimization

IPC-based sync compositor software draw optimization

Instead of allocating and mapping a new chunk of shared memory segment
in each draw synchronously, re-use the same segment if the sizes match
exactly.

Break software draws into 3 IPCs:
SetSharedMemory: synchronous, pass the shared memory handle to be used
                 for subsequent software draws to renderer
DemandDrawSw: synchronous, the draw itself
ZeroSharedMemory: asynchronous, zeros shared memory on renderer side,
                  sent after each DemandDrawSw after browser is done
                  reading from the shared memory.

ZeroSharedMemory is asynchronous so zero-ing the memory can be done in
parallel. Note messages on renderer are ordered, so ZeroSharedMemory
is guaranteed to be handled before the next DemandDrawSw.

BUG=545611
Committed: https://crrev.com/cafb1bf5df2fff9340fbeefb5ed3b7aaa22a4599
Cr-Commit-Position: refs/heads/master@{#367036}

[boliu, 2015-12-22 20:16:20]

Description was changed from

==========
IPC-based sync compositor software draw optimization

Instead of allocating and mapping a new chunk of shared memory segment
in each draw synchronously, re-use the same segment if the sizes match
exactly.

Break software draws into 3 IPCs:
SetSharedMemory: synchronous, pass the shared memory handle to be used
                 for subsequent software draws to renderer
DemandDrawSw: synchronous, the draw itself
ZeroSharedMemory: asynchronous, zeros shared memory on renderer side,
                  sent after each DemandDrawSw after browser is done
                  reading from the shared memory.

ZeroSharedMemory is asynchronous so zero-ing the memory can be done in
parallel.

BUG=545611
==========

to

==========
IPC-based sync compositor software draw optimization

Instead of allocating and mapping a new chunk of shared memory segment
in each draw synchronously, re-use the same segment if the sizes match
exactly.

Break software draws into 3 IPCs:
SetSharedMemory: synchronous, pass the shared memory handle to be used
                 for subsequent software draws to renderer
DemandDrawSw: synchronous, the draw itself
ZeroSharedMemory: asynchronous, zeros shared memory on renderer side,
                  sent after each DemandDrawSw after browser is done
                  reading from the shared memory.

ZeroSharedMemory is asynchronous so zero-ing the memory can be done in
parallel. Note messages on renderer are ordered, so ZeroSharedMemory
is guaranteed to be handled before the next DemandDrawSw.

BUG=545611
==========

[boliu, 2015-12-23 00:36:22]

Description was changed from

==========
IPC-based sync compositor software draw optimization

Instead of allocating and mapping a new chunk of shared memory segment
in each draw synchronously, re-use the same segment if the sizes match
exactly.

Break software draws into 3 IPCs:
SetSharedMemory: synchronous, pass the shared memory handle to be used
                 for subsequent software draws to renderer
DemandDrawSw: synchronous, the draw itself
ZeroSharedMemory: asynchronous, zeros shared memory on renderer side,
                  sent after each DemandDrawSw after browser is done
                  reading from the shared memory.

ZeroSharedMemory is asynchronous so zero-ing the memory can be done in
parallel. Note messages on renderer are ordered, so ZeroSharedMemory
is guaranteed to be handled before the next DemandDrawSw.

BUG=545611
==========

to

==========
IPC-based sync compositor software draw optimization

Instead of allocating and mapping a new chunk of shared memory segment
in each draw synchronously, re-use the same segment if the sizes match
exactly.

Break software draws into 2 IPCs:
SetSharedMemory: synchronous, pass the shared memory handle to be used
                 for subsequent software draws to renderer
DemandDrawSw: synchronous, the draw itself

There is no need to worry about zero-ing the memory before each
draw since compositor is supposed to draw the whole clip.

BUG=545611
==========

[boliu, 2015-12-23 00:44:55]

Description was changed from

==========
IPC-based sync compositor software draw optimization

Instead of allocating and mapping a new chunk of shared memory segment
in each draw synchronously, re-use the same segment if the sizes match
exactly.

Break software draws into 2 IPCs:
SetSharedMemory: synchronous, pass the shared memory handle to be used
                 for subsequent software draws to renderer
DemandDrawSw: synchronous, the draw itself

There is no need to worry about zero-ing the memory before each
draw since compositor is supposed to draw the whole clip.

BUG=545611
==========

to

==========
IPC-based sync compositor software draw optimization

Instead of allocating and mapping a new chunk of shared memory segment
in each draw synchronously, re-use the same segment if the sizes match
exactly.

Break software draws into 2 IPCs:
SetSharedMemory: synchronous, pass the shared memory handle to be used
                 for subsequent software draws to renderer
DemandDrawSw: synchronous, the draw itself

There is no need to worry about zero-ing the memory before each
draw since the size matches exactly, and compositor should draw
the entire viewport/clip.

BUG=545611
==========

[boliu, 2015-12-23 00:57:27]

Description was changed from

==========
IPC-based sync compositor software draw optimization

Instead of allocating and mapping a new chunk of shared memory segment
in each draw synchronously, re-use the same segment if the sizes match
exactly.

Break software draws into 2 IPCs:
SetSharedMemory: synchronous, pass the shared memory handle to be used
                 for subsequent software draws to renderer
DemandDrawSw: synchronous, the draw itself

There is no need to worry about zero-ing the memory before each
draw since the size matches exactly, and compositor should draw
the entire viewport/clip.

BUG=545611
==========

to

==========
IPC-based sync compositor software draw optimization

Instead of allocating and mapping a new chunk of shared memory segment
in each draw synchronously, re-use the same segment if the sizes match
exactly.

Break software draws into 3 IPCs:
SetSharedMemory: synchronous, pass the shared memory handle to be used
                 for subsequent software draws to renderer
DemandDrawSw: synchronous, the draw itself
ZeroSharedMemory: asynchronous, zeros shared memory on renderer side,
                  sent after each DemandDrawSw after browser is done
                  reading from the shared memory.

ZeroSharedMemory is asynchronous so zero-ing the memory can be done in
parallel. Note messages on renderer are ordered, so ZeroSharedMemory
is guaranteed to be handled before the next DemandDrawSw.

BUG=545611
==========

[boliu, 2015-12-23 00:58:11]

boliu@chromium.org changed reviewers:
+ dcheng@chromium.org

[boliu, 2015-12-23 00:58:11]

no rush or anything, but ptal

and happy holidays :)

[dcheng, 2015-12-29 00:00:24]

https://codereview.chromium.org/1541203003/diff/80001/content/browser/android...
File content/browser/android/synchronous_compositor_host.cc (right):

https://codereview.chromium.org/1541203003/diff/80001/content/browser/android...
content/browser/android/synchronous_compositor_host.cc:105:
SynchronousCompositorHost* host_;
Nit: T* const.

https://codereview.chromium.org/1541203003/diff/80001/content/browser/android...
content/browser/android/synchronous_compositor_host.cc:117: };
DISALLOW_COPY_AND_ASSIGN here too?

https://codereview.chromium.org/1541203003/diff/80001/content/browser/android...
content/browser/android/synchronous_compositor_host.cc:208: software_draw_shm_ =
std::move(software_draw_shm);
#include <utility>

https://codereview.chromium.org/1541203003/diff/80001/content/renderer/androi...
File content/renderer/android/synchronous_compositor_proxy.cc (right):

https://codereview.chromium.org/1541203003/diff/80001/content/renderer/androi...
content/renderer/android/synchronous_compositor_proxy.cc:251:
CHECK(software_draw_shm_);
Why CHECK here?

[boliu, 2015-12-29 00:16:30]

https://codereview.chromium.org/1541203003/diff/80001/content/browser/android...
File content/browser/android/synchronous_compositor_host.cc (right):

https://codereview.chromium.org/1541203003/diff/80001/content/browser/android...
content/browser/android/synchronous_compositor_host.cc:105:
SynchronousCompositorHost* host_;
On 2015/12/29 00:00:24, dcheng wrote:
> Nit: T* const.

Done.

https://codereview.chromium.org/1541203003/diff/80001/content/browser/android...
content/browser/android/synchronous_compositor_host.cc:117: };
On 2015/12/29 00:00:24, dcheng wrote:
> DISALLOW_COPY_AND_ASSIGN here too?

Done.

https://codereview.chromium.org/1541203003/diff/80001/content/browser/android...
content/browser/android/synchronous_compositor_host.cc:208: software_draw_shm_ =
std::move(software_draw_shm);
On 2015/12/29 00:00:24, dcheng wrote:
> #include <utility>

Done.

https://codereview.chromium.org/1541203003/diff/80001/content/renderer/androi...
File content/renderer/android/synchronous_compositor_proxy.cc (right):

https://codereview.chromium.org/1541203003/diff/80001/content/renderer/androi...
content/renderer/android/synchronous_compositor_proxy.cc:251:
CHECK(software_draw_shm_);
On 2015/12/29 00:00:24, dcheng wrote:
> Why CHECK here?

in case if I forgot an edge case and an NPE happens in production, have it
generate an error message and clean stack trace to identify it

a bit pessimistic I guess.. Didn't make any changes in PS6

[dcheng, 2015-12-29 00:29:52]

lgtm

https://codereview.chromium.org/1541203003/diff/80001/content/renderer/androi...
File content/renderer/android/synchronous_compositor_proxy.cc (right):

https://codereview.chromium.org/1541203003/diff/80001/content/renderer/androi...
content/renderer/android/synchronous_compositor_proxy.cc:251:
CHECK(software_draw_shm_);
On 2015/12/29 at 00:16:30, boliu wrote:
> On 2015/12/29 00:00:24, dcheng wrote:
> > Why CHECK here?
> 
> in case if I forgot an edge case and an NPE happens in production, have it
generate an error message and clean stack trace to identify it
> 
> a bit pessimistic I guess.. Didn't make any changes in PS6

I'd prefer to remove this, it's going to crash on line 253 anyway. I would
assume that we use the same stack unwinder for CHECK and general crashes, so
there's no real meaningful difference.

[boliu, 2015-12-29 00:32:29]

thanks :)

https://codereview.chromium.org/1541203003/diff/80001/content/renderer/androi...
File content/renderer/android/synchronous_compositor_proxy.cc (right):

https://codereview.chromium.org/1541203003/diff/80001/content/renderer/androi...
content/renderer/android/synchronous_compositor_proxy.cc:251:
CHECK(software_draw_shm_);
On 2015/12/29 00:29:52, dcheng wrote:
> On 2015/12/29 at 00:16:30, boliu wrote:
> > On 2015/12/29 00:00:24, dcheng wrote:
> > > Why CHECK here?
> > 
> > in case if I forgot an edge case and an NPE happens in production, have it
> generate an error message and clean stack trace to identify it
> > 
> > a bit pessimistic I guess.. Didn't make any changes in PS6
> 
> I'd prefer to remove this, it's going to crash on line 253 anyway. I would
> assume that we use the same stack unwinder for CHECK and general crashes, so
> there's no real meaningful difference.

Sure. Done

[boliu, 2015-12-29 00:33:28]

The CQ bit was checked by boliu@chromium.org

[boliu, 2015-12-29 00:33:29]

The patchset sent to the CQ was uploaded after l-g-t-m from dcheng@chromium.org
Link to the patchset: https://codereview.chromium.org/1541203003/#ps120001
(title: "remove CHECK")

[commit-bot: I haz the power, 2015-12-29 00:33:39]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1541203003/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1541203003/120001

[commit-bot: I haz the power, 2015-12-29 01:40:26]

Description was changed from

==========
IPC-based sync compositor software draw optimization

Instead of allocating and mapping a new chunk of shared memory segment
in each draw synchronously, re-use the same segment if the sizes match
exactly.

Break software draws into 3 IPCs:
SetSharedMemory: synchronous, pass the shared memory handle to be used
                 for subsequent software draws to renderer
DemandDrawSw: synchronous, the draw itself
ZeroSharedMemory: asynchronous, zeros shared memory on renderer side,
                  sent after each DemandDrawSw after browser is done
                  reading from the shared memory.

ZeroSharedMemory is asynchronous so zero-ing the memory can be done in
parallel. Note messages on renderer are ordered, so ZeroSharedMemory
is guaranteed to be handled before the next DemandDrawSw.

BUG=545611
==========

to

==========
IPC-based sync compositor software draw optimization

Instead of allocating and mapping a new chunk of shared memory segment
in each draw synchronously, re-use the same segment if the sizes match
exactly.

Break software draws into 3 IPCs:
SetSharedMemory: synchronous, pass the shared memory handle to be used
                 for subsequent software draws to renderer
DemandDrawSw: synchronous, the draw itself
ZeroSharedMemory: asynchronous, zeros shared memory on renderer side,
                  sent after each DemandDrawSw after browser is done
                  reading from the shared memory.

ZeroSharedMemory is asynchronous so zero-ing the memory can be done in
parallel. Note messages on renderer are ordered, so ZeroSharedMemory
is guaranteed to be handled before the next DemandDrawSw.

BUG=545611
==========

[commit-bot: I haz the power, 2015-12-29 01:40:26]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2015-12-29 01:41:39]

Description was changed from

==========
IPC-based sync compositor software draw optimization

Instead of allocating and mapping a new chunk of shared memory segment
in each draw synchronously, re-use the same segment if the sizes match
exactly.

Break software draws into 3 IPCs:
SetSharedMemory: synchronous, pass the shared memory handle to be used
                 for subsequent software draws to renderer
DemandDrawSw: synchronous, the draw itself
ZeroSharedMemory: asynchronous, zeros shared memory on renderer side,
                  sent after each DemandDrawSw after browser is done
                  reading from the shared memory.

ZeroSharedMemory is asynchronous so zero-ing the memory can be done in
parallel. Note messages on renderer are ordered, so ZeroSharedMemory
is guaranteed to be handled before the next DemandDrawSw.

BUG=545611
==========

to

==========
IPC-based sync compositor software draw optimization

Instead of allocating and mapping a new chunk of shared memory segment
in each draw synchronously, re-use the same segment if the sizes match
exactly.

Break software draws into 3 IPCs:
SetSharedMemory: synchronous, pass the shared memory handle to be used
                 for subsequent software draws to renderer
DemandDrawSw: synchronous, the draw itself
ZeroSharedMemory: asynchronous, zeros shared memory on renderer side,
                  sent after each DemandDrawSw after browser is done
                  reading from the shared memory.

ZeroSharedMemory is asynchronous so zero-ing the memory can be done in
parallel. Note messages on renderer are ordered, so ZeroSharedMemory
is guaranteed to be handled before the next DemandDrawSw.

BUG=545611

Committed: https://crrev.com/cafb1bf5df2fff9340fbeefb5ed3b7aaa22a4599
Cr-Commit-Position: refs/heads/master@{#367036}
==========

[commit-bot: I haz the power, 2015-12-29 01:41:40]

Patchset 7 (id:??) landed as
https://crrev.com/cafb1bf5df2fff9340fbeefb5ed3b7aaa22a4599
Cr-Commit-Position: refs/heads/master@{#367036}