These functions didn't be used by anyone, remove them.
MozReview-Commit-ID: BLj8GsVp1gR
--HG--
extra : rebase_source : 1b7eee86c62314401c2374a2979ba2a42fda2490
Sub-classes should know how to pin/unpin the resource.
MozReview-Commit-ID: 50S8oSD5oEU
--HG--
extra : rebase_source : 5e1b7c657b759c0d1dfdd7b5c0a4b7dbc4077ffe
extra : intermediate-source : 3000b76a3b97c08955c2d584ac215114c8e8f59a
extra : source : a56b9846db916ff85a0cae09736c3284bd895506
On platforms with MOZ_SAMPLE_TYPE_S16, decode and resampling was already
performed in 16-bit arithmetic. Keeping the potentially large buffer in
16-bit format halves the memory usage.
This patch does not affect other platforms.
MozReview-Commit-ID: DWZdiPNasie
--HG--
extra : rebase_source : b6a7191357c64888455ee111f02da75f208d2df7
for sharing with a new factory method in a future patch.
MozReview-Commit-ID: LAtbRVttMh8
--HG--
extra : rebase_source : 72283c49fd713d0aef3add0eae344da0733149a1
This is mostly to be consistent with other nodes so that only a single
SetBuffer method is required to pass buffers from nodes to engines.
AudioChunk also has the advantage of ThreadSharedFloatArrayBufferList that it
keeps a record of the length of the buffer in the same struct, and so this is
passed to the engine with the buffer.
SharedBuffer needs one fewer allocation than ThreadSharedFloatArrayBufferList,
but this is not a hot path.
MozReview-Commit-ID: JsLcuFdFvRO
--HG--
extra : rebase_source : 00ffc0a357ec248641063e77dbe63e8d2a4a0911
Although the AudioChunk buffer is still always a
ThreadSharedFloatArrayBufferList, 16 bit buffers will be permitted in a future
patch.
MozReview-Commit-ID: FPZ6VcX4C1q
--HG--
extra : rebase_source : dc0d82d5495383ab2aaca37a09d282dd3c747e83
Although the AudioChunk buffer is still always a
ThreadSharedFloatArrayBufferList, buffers with 16-bit data will be permitted
in a future patch.
MozReview-Commit-ID: FEGKMiQOCpR
--HG--
extra : rebase_source : 29680252fac272feda26ba65dd1ca86e0e9d5883
This enables VP9 decoding on Windows with AMD graphic adapters supporting it.
The AMD VP9 MFT only works 720 and more pixels high.
The system will attempt the following decoding configuration:
1- AMD VP9 MFT
2- Microsoft VP9 MFT (only if DXVA is enabled)
3- FFmpeg ffvp9 software decoder
MozReview-Commit-ID: IP2eHZEQ7Tj
--HG--
extra : rebase_source : 6d193aa8b9d22f8df5778c7e62f66c30e9dc600c
We will move the implementation to sub-classes which have more details
about how to calculate the resource size.
MozReview-Commit-ID: 7lfiz5GNtPE
--HG--
extra : rebase_source : bf14ef91a6de456d65bee7cb1f53f8e542f55247
extra : source : 22640df9dd3a1491594a82b3d0bd175e46073fa3
Change webextensions experiments test to use the shimmed certficiate DB
instead of the extensions.legacy.enabled pref.
In builds that don't honor the extensions.legacy.enabled pref, disable
test_legacy.js since that tests that flipping that preference works properly.
Finally, remove a now doubly-obsolete test of plugins embedded in xpis.
MozReview-Commit-ID: JiRdgCXyjKR
--HG--
extra : rebase_source : f0c7672b0755993bd20f9fc84e242eb76cb949ef
This test called waitForPaints() after creating an animation, but waitForPaints()
didn't wait for a MozAfterPaint event actually since
DOMWindowUtils.IsMozAfterPaintPending which is checked a MozAfterPaint event has
been queued return false[1]. (i.e. This test didn't wait for a MozAfterPaint)
This is related to bug 1341294. If gecko can receive a MozAfterPaint
corresponded to own paint, waitForPaint() does not need to check for
DOMWindowUtils.IsMozAfterPaintPending.
This patch is a workaround until bug 1341294 is resolved.
[1] http://searchfox.org/mozilla-central/rev/5696c3e525fc8222674eed6a562f5fcbe804c4c7/testing/mochitest/tests/SimpleTest/paint_listener.js#60
MozReview-Commit-ID: 6Rnv8MBP6Se
--HG--
extra : rebase_source : 052f62b01df819961040f6652954e1068f86fc47
Similar to Selection::Collapse(), if mCachedRange is available,
Selection::SetBaseAndExtent() should use it rather than creating new nsRange
instance.
Then, it can reduce the allocation cost and may reduce some other cost, e.g.,
adding it to mutation observer.
MozReview-Commit-ID: InQQusw2KMc
--HG--
extra : rebase_source : 967f0d4ad2b7bc706e417af547bbbb21e5f54306
When setting value of <input type="text">, nsTextEditorState removes all
ranges of normal selection first. Then, TextEditor sets the value. Finally,
TextEditor collapses the selection at the end of the text.
In bug 1386471, we got that there are some problems to remove the call of
Selection::RemoveAllRanges() in nsTextEditorState. Therefore, we need another
approach to improve Selection::Collapse().
The approach of this patch is, when removing all ranges from normal selection,
Selection can cache an nsRange instance if there is an instance which is not
referenced from other than the Selection (i.e., it'll be removed when
Selection::Clear() is called). Then, Selection::Collapse() can reuse it. With
this fix, Selection::Collapse() can reduce allocation cost and may reduce some
other cost like adding it to mutation observer.
However, keeping nsRange instance may cause increasing mutation observer's cost
since nsRange will be adjusted its start node/offset and end node/offset with
mutation observer to guarantee that the range is always valid. So, we can
cache such range only when the caller (or its callee) will set selection range
later. Therefore, this patch adds Selection::RemoveAllRangesTemporarily()
and make only nsTextEditorState::SetValue() and
ContentEventHandler::OnSelectionEvent() use it.
MozReview-Commit-ID: FjWrbz4S1ld
--HG--
extra : rebase_source : 83677640525e0b1a84bdd7fce63ff4704b9cc22b
