Usually, mShouldFallbackIfError has been reset to false in DataCallback()
before Stop() is called. However, if fallback to a system clock driver due to
cubeb error had already occurred, then mShouldFallbackIfError would not have
been reset, and Stop() is still called. With mShouldFallbackIfError still
true, a cubeb error in stop would have created another fallback thread.
I expect that resetting mShouldFallbackIfError in Stop() would also be an
effective alternative solution, but resetting on StateCallback() happens
earlier, which would be an advantage if any additional errors could possibly
be reported to StateCallback().
MozReview-Commit-ID: E9j7PQmS3O4
--HG--
extra : rebase_source : 200993c9e99475101c429005cfadb7260df29067
This adds back the `framerate` update that was removed in bug 1299515.
It also fixes a threading issue (not really an issue, but it broke the
documented policy) where Start() wrote to mCapability without holding mMutex.
MozReview-Commit-ID: Jda5moNhlkM
--HG--
extra : rebase_source : a8f27f064b9f818eb29aa72a18605786c474631b
Most importantly, this reduces the number of copies to 1 in the common case.
In a case where we are rescaling because there are competing gUM requests
this does two copies, where one is the crop-and-scale operation itself.
In the worst case we do two allocations, but with a buffer pool and a recycling
ImageContainer we allocate very rarely in practice.
MozReview-Commit-ID: B0Et4wZol9n
--HG--
extra : rebase_source : e0950a53278336773570c9e989a21392195f8898
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <