NOT for review (for discussion): Query IOSurfaceIsInUse in the browser process

NOT for review (for discussion): Query IOSurfaceIsInUse in the browser process

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

[ccameron, 2016-11-03 07:16:37]

Description was changed from

==========
NOT for review (for discussion): Query IOSurfaceIsInUse in the browser process

BUG=
==========

to

==========
NOT for review (for discussion): Query IOSurfaceIsInUse in the browser process

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[ccameron, 2016-11-03 07:16:38]

Description was changed from

==========
NOT for review (for discussion): Query IOSurfaceIsInUse in the browser process

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
NOT for review (for discussion): Query IOSurfaceIsInUse in the browser process

BUG=
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
==========

[ccameron, 2016-11-03 07:22:17]

ccameron@chromium.org changed reviewers:
+ erikchen@chromium.org

[ccameron, 2016-11-03 07:22:17]

This is all that is needed to get IOSurfaces open in the browser process ...
much simpler than the previous approaches.

It also makes the "lock for overlay" versus "lock for CALayer" completely
separate in GLRenderer, which seems reasonable to me.

Having finished this, I think that we should actually add an automatic ACK for
all textures that are sent using ScheduleCALayerCHROMIUM, and not even have the
separate "query in use" call.

What I haven't done yet is evaluate the power overhead of opening an extra Mach
port. If that's too high, then this is a no-go. I'll measure that tomorrow
afternoon (IIRC you mentioned that opening ports was among the biggest costs in
the window server).

So, WDYT? Is this worth pursuing? What I'd like to agitate for is:
- if this increases power, then shelve it
- if this doesn't increase power, then enable it
- if this is enabled, then add support for a browser CALayer tree behind finch
- use finch to evaluate the stability of the two approaches
- if stability is improved, go with browser CALayers

[erikchen, 2016-11-03 18:13:35]

On 2016/11/03 07:22:17, ccameron wrote:
> This is all that is needed to get IOSurfaces open in the browser process ...
> much simpler than the previous approaches.
> 
> It also makes the "lock for overlay" versus "lock for CALayer" completely
> separate in GLRenderer, which seems reasonable to me.
> 
> Having finished this, I think that we should actually add an automatic ACK for
> all textures that are sent using ScheduleCALayerCHROMIUM, and not even have
the
> separate "query in use" call.
> 
> What I haven't done yet is evaluate the power overhead of opening an extra
Mach
> port. If that's too high, then this is a no-go. I'll measure that tomorrow
> afternoon (IIRC you mentioned that opening ports was among the biggest costs
in
> the window server).
Opening a Mach port for an IOSurface is the slowest part of sending it to the
window server in a CATransaction. IIRC, 100 surfaces takes 2.5ms.

> 
> So, WDYT? Is this worth pursuing? What I'd like to agitate for is:
> - if this increases power, then shelve it
I think stability is more important than power. I would like to factor that into
the calculation before shelving it. I guess my feelings about this CL depend on
just how deprecated RemoteCALayers are. Without further information, I'd say go
for it.

> - if this doesn't increase power, then enable it
> - if this is enabled, then add support for a browser CALayer tree behind finch
> - use finch to evaluate the stability of the two approaches
> - if stability is improved, go with browser CALayers