1. 20 Oct, 2014 26 commits
  2. 19 Oct, 2014 7 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
    • dstockwell@chromium.org's avatar
      Revert of Oilpan: move ScriptLoader to the heap. (patchset #3 id:2 of... · efdff89e
      dstockwell@chromium.org authored
      Revert of Oilpan: move ScriptLoader to the heap. (patchset #3 id:2 of https://codereview.chromium.org/660233002/)
      
      Reason for revert:
      Depends on https://codereview.chromium.org/656113002 which introduced memory leaks.
      
      Original issue's description:
      > Oilpan: move ScriptLoader to the heap.
      > 
      > So as to be able to trace its PendingScript part object.
      > 
      > R=haraken
      > BUG=
      > 
      > Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=183909
      
      TBR=oilpan-reviews@chromium.org,haraken@chromium.org,sigbjornf@opera.com
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/656413003
      
      git-svn-id: svn://svn.chromium.org/blink/trunk@183951 bbb929c8-8fbe-4397-9dbb-9b2b20218538
      efdff89e
    • dstockwell@chromium.org's avatar
      Web Animations: Plumb compositor group id through animation creation and start/finish notifications · c70ec791
      dstockwell@chromium.org authored
      This is required for Blink to track the synchronized starting of groups of
      animations.
      
      Depends on a change in chromium: https://codereview.chromium.org/653563003
      Follow on usage: https://codereview.chromium.org/651103002
      
      BUG=423265
      
      Review URL: https://codereview.chromium.org/652593003
      
      git-svn-id: svn://svn.chromium.org/blink/trunk@183950 bbb929c8-8fbe-4397-9dbb-9b2b20218538
      c70ec791
    • senorblanco@chromium.org's avatar
      Remove the deferredFiltersFlag (now unused). · cc96edd5
      senorblanco@chromium.org authored
      R=junov@chromium.org
      
      BUG=
      
      Review URL: https://codereview.chromium.org/658653003
      
      git-svn-id: svn://svn.chromium.org/blink/trunk@183949 bbb929c8-8fbe-4397-9dbb-9b2b20218538
      cc96edd5
    • pfeldman@chromium.org's avatar
    • bratell@opera.com's avatar
      Expanding Type Traits to make Vector use mem ops more. · 61cdd932
      bratell@opera.com authored
      Vector has several code paths depending on whether the encapsulated
      object can be handled with memmove/memcpy/memset or not. The fast path
      with memops is used by many objects, but unfortunately that 
      requires manual hinting in every class because the type traits 
      used are not strong enough.
      
      By using type trait functions available in all modern compilers it's
      possible to more intelligently select the most optimal code path.
      
      Preferably the code would use the new type traits in C++ 11 but
      unfortunately that requires a modern c++ library. Luckily, those
      libraries are mostly just thin wrappers on top of de facto-standard
      compiler extension functions anyway.
      
      With clang this cuts away 105 KB of machine code in blink. Mostly by 
      no longer needing copy constructor and assignment operators in many
      classes so those can be stripped from the binary. 
      
      With gcc the changes are differently. The binary is smaller but only 
      by 5 KB. It's clear that many Vector methods have become more compact but
      it seems gcc compensated by spending that space elsewhere (more inlining?).
      
      I don't have as good measurement tools for Visual Studio but there was no
      huge difference in footprint.
      
      Performance, all this is from a noisy development computer with a 
      non-stable cpu clock frequency (turbo ftl...):
      
      In LayoutTests most changes are within noise levels. But it looks like 
      large tables and flexboxes might be 1-5% faster. In ParserTests 
      html5-full-render (macro-benchmark) became 2-3% faster. There were also
      indications that some micro-benchmarks became 30% faster since reverting
      an earlier version of this caused that size performance regressions.
      
      clang footprint numbers:
      Total change: -109940 bytes
      ===========================
        14 added, totalling +3397 bytes across 8 sources
        19 removed, totalling -13302 bytes across 6 sources
        8 grown, for a net change of +578 bytes (2268 bytes before, 2846 bytes after) across 6 sources
        230 shrunk, for a net change of -100613 bytes (190909 bytes before, 90296 bytes after) across 49 sources
      
      Biggest changes:
       -84410 - Source: /home/bratell/src/chromium/src/third_party/WebKit/Source/wtf/Vector.h - (gained 784, lost 85194)
        -6934 - Source: /home/bratell/src/chromium/src/third_party/WebKit/Source/wtf/Deque.h - (gained 0, lost 6934)
        -2267 - Source: /home/bratell/src/chromium/src/third_party/WebKit/Source/core/animation/css/CSSAnimationData.cpp - (gained 904, lost 3171)
      ...
         +245 - Source: /home/bratell/src/chromium/src/third_party/WebKit/Source/core/svg/animation/SVGSMILElement.cpp - (gained 245, lost 0)
      
      BUG=
      R=jochen@chromium.org
      
      Review URL: https://codereview.chromium.org/594023002
      
      git-svn-id: svn://svn.chromium.org/blink/trunk@183947 bbb929c8-8fbe-4397-9dbb-9b2b20218538
      61cdd932
  3. 18 Oct, 2014 7 commits