Canvas capture from inactive tab

Canvas capture from inactive tab

When there is captureStream() from a <canvas> on a backgrounded tab,
canvas stops updating frames and stream is muted. We want to avoid
this situation by avoiding the tab from being hidden during the lifetime of
canvas capture. 

BUG=500605

[emircan, 2016-02-09 23:10:34]

Description was changed from

==========
new sol.

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

to

==========
Canvas Capture from inactive tab

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

[emircan, 2016-02-10 00:24:16]

Patchset #2 (id:20001) has been deleted

[emircan, 2016-02-10 02:16:06]

Patchset #2 (id:40001) has been deleted

[emircan, 2016-02-12 19:53:29]

Patchset #1 (id:1) has been deleted

[emircan, 2016-02-12 19:53:35]

Patchset #1 (id:60001) has been deleted

[emircan, 2016-02-12 19:58:36]

Description was changed from

==========
Canvas Capture from inactive tab

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

to

==========
Canvas capture from inactive tab

When there is captureStream() from a <canvas> on a backgrounded tab,
canvas stops updating frames and stream stops as well. We want to avoid
this situation by avoiding the tab from being hidden during the lifetime of
capture. 

BUG=500605
==========

[emircan, 2016-02-12 19:59:35]

Description was changed from

==========
Canvas capture from inactive tab

When there is captureStream() from a <canvas> on a backgrounded tab,
canvas stops updating frames and stream stops as well. We want to avoid
this situation by avoiding the tab from being hidden during the lifetime of
capture. 

BUG=500605
==========

to

==========
Canvas capture from inactive tab

When there is captureStream() from a <canvas> on a backgrounded tab,
canvas stops updating frames and stream is muted. We want to avoid
this situation by avoiding the tab from being hidden during the lifetime of
capture. 

BUG=500605
==========

[emircan, 2016-02-12 19:59:49]

Description was changed from

==========
Canvas capture from inactive tab

When there is captureStream() from a <canvas> on a backgrounded tab,
canvas stops updating frames and stream is muted. We want to avoid
this situation by avoiding the tab from being hidden during the lifetime of
capture. 

BUG=500605
==========

to

==========
Canvas capture from inactive tab

When there is captureStream() from a <canvas> on a backgrounded tab,
canvas stops updating frames and stream is muted. We want to avoid
this situation by avoiding the tab from being hidden during the lifetime of
canvas capture. 

BUG=500605
==========

[emircan, 2016-02-12 20:04:59]

emircan@chromium.org changed reviewers:
+ miu@chromium.org

[emircan, 2016-02-12 20:05:00]

miu@ can you take the first look since it is referring to
IncrementCapturerCount()&DecrementCapturerCount()?

[miu, 2016-02-22 22:58:51]

miu@chromium.org changed reviewers:
+ jam@chromium.org

[miu, 2016-02-22 23:03:49]

On 2016/02/12 20:05:00, emircan wrote:
> miu@ can you take the first look since it is referring to
> IncrementCapturerCount()&DecrementCapturerCount()?

[ +jam@ for architecture knowledge, and to advise here ]

I'm not sure this is the right approach.  The Increment/DecrementCapturerCount()
is used in the browser process to cause a few different behaviors to change, one
of which is to keep a hidden tab from being notified it is hidden.  In fact,
I've been meaning to clean this up a bit (there are some open crbugs assigned to
me about that).

Instead, what we have here is a renderer that self-captures some of its content
(from a Canvas).  It seems that your problem might be solved by simply enabling
painting in RenderWidget (renderer-side), despite what any show/hidden IPCs from
the browser process are instructing the renderer to do.  Thus, I think the
override logic probably needs to be around here:
https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/r...

However, I suggest asking an OWNER of content::RenderWidget--someone more
familiar with the architecture--what the best approach might be here.  There may
be an easy way to isolate painting to just the Canvas, and not have to enable it
renderer-wide.

[esprehn, 2016-02-22 23:44:30]

On 2016/02/22 at 23:03:49, miu wrote:
> ...
> 
> However, I suggest asking an OWNER of content::RenderWidget--someone more
familiar with the architecture--what the best approach might be here.  There may
be an easy way to isolate painting to just the Canvas, and not have to enable it
renderer-wide.

That doesn't seem quite right to me, the tab needs to think it's fully visible
if raf is going to run. That means the whole stack should assume it's visible.

[miu, 2016-02-22 23:59:34]

On 2016/02/22 23:44:30, esprehn wrote:
> On 2016/02/22 at 23:03:49, miu wrote:
> > ...
> > 
> > However, I suggest asking an OWNER of content::RenderWidget--someone more
> familiar with the architecture--what the best approach might be here.  There
may
> be an easy way to isolate painting to just the Canvas, and not have to enable
it
> renderer-wide.
> 
> That doesn't seem quite right to me, the tab needs to think it's fully visible
> if raf is going to run. That means the whole stack should assume it's visible.

Sounds good.  So, then, when you say "whole stack" do you mean just the "whole
renderer?"  In other words, would there be any problem (architecturally) with a
renderer ignoring the browser's ViewMsg_WasHidden IPC?  The comment here suggest
that would be acceptable:
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/vie...

[miu, 2016-03-29 20:13:59]

Ping.  Is this change still WIP?

[emircan, 2016-03-29 21:13:23]

Closing now. Thanks for the feedback.