Intent to Implement: Pause Worklets and Dedicated Workers Execution on document freeze

55 views
Skip to first unread message

Dave Tapuska

unread,
May 14, 2019, 1:27:41 PM5/14/19
to blink-dev
dtap...@chromium.org https://github.com/WICG/page-lifecycle/pull/35 Specification: https://github.com/WICG/page-lifecycle/pull/35 https://github.com/WICG/page-lifecycle/pull/35 Considered a bug part of freezing lifecycle that was underspecified. Dedicated workers and worklets continue to execute even though documents may be frozen due to the page lifecycle. All threads in a frozen document should be frozen.
Some risk for pages that might be doing work in workers where they will see their workflow paused. eg. A background worker uploading or downloading files. Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals
Yes Yes https://wpt.fyi/results/lifecycle/worker-dispay-none.tentative.html?label=master&product=chrome%5Bexperimental%5D&product=edge&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned https://www.chromestatus.com/features/5276568928649216

Ben Kelly

unread,
May 14, 2019, 1:39:54 PM5/14/19
to Dave Tapuska, blink-dev
On Tue, May 14, 2019 at 1:27 PM Dave Tapuska <dtap...@chromium.org> wrote:
Dedicated workers and worklets continue to execute even though documents may be frozen due to the page lifecycle. All threads in a frozen document should be frozen.
 
Firefox: No public signals

Not to say this is a public signal on how this relates to freezing with page lifecycle, but firefox does currently pause dedicated workers when a document is frozen by going into bfcache.  So I think this is consistent with what they are implementing there.

Ben

Raymond Toy

unread,
May 14, 2019, 1:49:20 PM5/14/19
to Dave Tapuska, blink-dev
As we've discovered, WebAudio's OfflineAudioContext's don't pause.  And there's currently no API to pause these.

I think that they probably should.  If the offline context is rendering a large number of samples and the graph has a ScriptProcessorNode or AudioWorkletNode, then there could be potentially a huge number of tasks posted to the main thread or other threads/workers.  I assume that's not what you want.

We'll need some guidance here on what you really need so we can come up with a way to pause/resume these.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZXHsLVLfHpzrTTE4tRg4PhpDvsUDwgOm434WACoooakqg%40mail.gmail.com.

Dave Tapuska

unread,
May 14, 2019, 1:56:11 PM5/14/19
to Raymond Toy, blink-dev
Raymond can you try with https://chromium-review.googlesource.com/c/chromium/src/+/1582265 and https://chromium-review.googlesource.com/c/chromium/src/+/1588158

Because the offline audio context is driven entirely from the scheduling in process itself (rather than an external pipeline like realtime audio). You should find that they do pause correctly. The worklet/worker scheduler end up pausing execution themselves which then makes it work for OfflineAudioContext. 

dave.

Raymond Toy

unread,
May 15, 2019, 12:26:25 PM5/15/19
to Dave Tapuska, blink-dev
From: Dave Tapuska <dtap...@chromium.org>
Date: Tue, May 14, 2019 at 10:56 AM
To: Raymond Toy
Cc: blink-dev


You mean apply both CLs?  Do you have a test I can use?

Because the offline audio context is driven entirely from the scheduling in process itself (rather than an external pipeline like realtime audio). You should find that they do pause correctly. The worklet/worker scheduler end up pausing execution themselves which then makes it work for OfflineAudioContext. 

That sounds good.  We should probably update the comment for fix you made to avoid NOT_REACHED() code. 

dave.

On Tue, May 14, 2019 at 1:49 PM Raymond Toy <rt...@chromium.org> wrote:
As we've discovered, WebAudio's OfflineAudioContext's don't pause.  And there's currently no API to pause these.

I think that they probably should.  If the offline context is rendering a large number of samples and the graph has a ScriptProcessorNode or AudioWorkletNode, then there could be potentially a huge number of tasks posted to the main thread or other threads/workers.  I assume that's not what you want.

We'll need some guidance here on what you really need so we can come up with a way to pause/resume these.

From: Dave Tapuska <dtap...@chromium.org>
Date: Tue, May 14, 2019 at 10:27 AM
To: blink-dev

dtap...@chromium.org https://github.com/WICG/page-lifecycle/pull/35 Specification: https://github.com/WICG/page-lifecycle/pull/35 https://github.com/WICG/page-lifecycle/pull/35 Considered a bug part of freezing lifecycle that was underspecified. Dedicated workers and worklets continue to execute even though documents may be frozen due to the page lifecycle. All threads in a frozen document should be frozen.
Some risk for pages that might be doing work in workers where they will see their workflow paused. eg. A background worker uploading or downloading files. Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals
Yes Yes https://wpt.fyi/results/lifecycle/worker-dispay-none.tentative.html?label=master&product=chrome%5Bexperimental%5D&product=edge&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned https://www.chromestatus.com/features/5276568928649216

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZXHsLVLfHpzrTTE4tRg4PhpDvsUDwgOm434WACoooakqg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Reply all
Reply to author
Forward
0 new messages