Skip to content

GitLab

T
tangled
Switch branch/tag
  1. 20 Oct, 2014 38 commits
  3. 19 Oct, 2014 2 commits
    • dstockwell@chromium.org's avatar
      Revert of Implement suspend/resume for AudioContext (patchset #13 id:260001 of... · f4a6c227
      dstockwell@chromium.org authored 
      Revert of Implement suspend/resume for AudioContext (patchset #13 id:260001 of https://codereview.chromium.org/625363004/)

Reason for revert:
Breaks webaudio/oscillator-sine.html on Windows

Original issue's description:
> Implement suspend/resume for AudioContext
> 
> WebAudio is adding a suspend()/resume() API:
> 
> https://github.com/WebAudio/web-audio-api/issues/361
> https://github.com/WebAudio/web-audio-api/issues/317
> 
> In more detail, here is the proposed additions to the spec:
> 
> New attribute "state" with values:
> paused
>   Currently paused (time is not proceeding, audio hardware may be powered down/released).
> running
>   Audio is being processed.
> released
>   AudioContext has been released, and can no longer be used to process audio. All system resources should be released.
> 
> void suspend()
> Suspends the progression of time in the audio context, allows any current buffer contents to be played to the destination and then allows the system to power down and/or release audio hardware. If the context has been released, an InvalidStateError MUST be thrown. This is generally useful when the application knows it will not need the AudioContext for some time, and wishes to let the audio hardware power down.
> 
> While the system is suspend, MediaStreams will have their output ignored; that is, data will be lost by the real time nature of media streams. HTMLMediaElements will similarly have their output ignored until the system is resumed. Audio Workers and ScriptProcessorNodes will simply not fire their onaudioprocess events while suspended, but will resume when resumed. For the purpose of AnalyserNode window functions, the data is considered as a continuous stream - i.e. the resume()/suspend() does not cause silence to appear in the AnalyserNode's stream of data.
> 
> Promise resume()
> Resumes the progression of time in the audio context, which may involve re-priming the frame buffer contents. The promise resolves when the system has re-acquired (if necessary) access to audio hardware and has begun streaming to the destination, or immediately (with no other effect) if the context is already running. The promise is rejected if the context has been released.
> 
> BUG=420106
> 
> Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=183916

TBR=haraken@chromium.org,tkent@chromium.org,yhirano@chromium.org,rtoy@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=420106

Review URL: https://codereview.chromium.org/663003002

git-svn-id: svn://svn.chromium.org/blink/trunk@183953 bbb929c8-8fbe-4397-9dbb-9b2b20218538
      f4a6c227
    • dstockwell@chromium.org's avatar
      Revert of Refactor Script(Loader|Runner): don't access Resources all over the... · ef38a731
      dstockwell@chromium.org authored 
      Revert of Refactor Script(Loader|Runner): don't access Resources all over the place... (patchset #5 id:80001 of https://codereview.chromium.org/656113002/)

Reason for revert:
Introduced leaks in the following tests:

fast/dom/HTMLScriptElement/append-child-adopt-node-error-crash.html
fast/dom/HTMLScriptElement/script-async-attr.html
fast/dom/HTMLScriptElement/script-load-events.html
fast/dom/URL-attribute-reflection.html
fast/events/onerror-bubbling.html
http/tests/cache/loaded-from-cache-after-reload.html
http/tests/cache/subresource-expiration-2.html
http/tests/cache/subresource-multiple-instances.html
http/tests/htmlimports/import-script-block-crossorigin-dynamic.html
http/tests/loading/script-priorities.html

Original issue's description:
> Refactor Script(Loader|Runner): don't access Resources all over the place...
> 
> ... but use proper layering instead.
> 
> PendingScript holds a Resource, and many places in the code are using both the
> PendingScript and the underlying Resource. For example, ScriptRunner holds a
> collection of PendingScripts, and ScriptLoaders then listen to the underlying
> Resources. This is confusing and error prone.
> 
> The Resource - ScriptLoader - PendingScript - Element love quadrangle is messy
> in general.  Both ScriptLoader and PendingScript refer to the Resource. The way
> to get ScriptLoader from PendingScript is via Element which PendingScript also
> holds. But there's no way to get PendingScript from ScriptLoader.
> 
> This CL makes ScriptRunner access the ScriptLoaders directly and moves the
> PendingScript to ScriptLoader. In addition, it makes ScriptRunner not access the
> Resource of the ScriptLoader directly.
> 
> This CL also cancels the hack from https://bugs.webkit.org/show_bug.cgi?id=92211
> (r139942) where it was speculated that a crash can be caused by ScriptLoader
> getting the notifyFinished notification twice because it doesn't unsubscribe yet
> when it gets the first one. The speculative fix was to made it nullify
> ScriptLoader::m_resource and check for the nullity later. This is pretty
> surprising, since the obvious solution would've been to just unsubscribe early
> enough (which is done by this CL).
> 
> Note a behavioral change: It's OK to call Resource::addClient even if the
> Resource is finished, and in that case, the client will be notified
> immediately. But PendingScript used to ASSERT that the Resource is not
> finished. This CL removes that restriction (the underlying Resource already
> handles adding clients to finished resources + made ScriptStreamer handle it
> too).
> 
> Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=183873

TBR=jochen@chromium.org,haraken@chromium.org,morrita@chromium.org,sigbjornf@opera.com,marja@chromium.org
NOTREECHECKS=true
NOTRY=true

Review URL: https://codereview.chromium.org/669503003

git-svn-id: svn://svn.chromium.org/blink/trunk@183952 bbb929c8-8fbe-4397-9dbb-9b2b20218538
      ef38a731