We pretty much rewrite the whole logic of duration calculation of MDSM.
The new logic is much simpler for we have only one duration to manage
which is mDuration. Below is the details of the code changes:
1. remove the mExplicitDuration mirror since it should be handled in MediaDecoder.
2. remove mObservedDuration and mDuration will take its place.
3. mDuration is updated from:
a. metadata
b. playback position as playback progresses.
c. buffer ranges.
4. change mDuration to be finite when playback reaches the end.
MozReview-Commit-ID: 1EmlWvmw1R2
--HG--
extra : rebase_source : 54110160af6e167cdb59b24e1c6be7901bf56269
extra : source : 6325e6ae2319cae62e4c08cfc38706c9ac056842
We will let MediaDecoder do the final adjustment.
MozReview-Commit-ID: NmPD3Cgsta
--HG--
extra : rebase_source : 97f15f7ec330706edb7651c52e2eef128ac427f6
extra : source : 45e94e9edc423de6d53776b70c9c25cc9f40ce30
The implementation will be shared by most of the sub-classes except OggDecoder
which needs to call demuxer->SetChainingEvents().
http://searchfox.org/mozilla-central/rev/f0e4ae5f8c40ba742214e89aba3f554da0b89a33/dom/media/ogg/OggDecoder.cpp#25
This helps reducing code changes whenever we add a field to MediaFormatReaderInit.
MozReview-Commit-ID: 5K8NY1oxol4
--HG--
extra : rebase_source : 7bc2a71ad9bd982ada51fd28d6a5b7c6f1d7395a
extra : source : cccd49795938ce53cd8eee597ec0ea4859543c37
Since Ahem.ttf is valid now, we should pass wbr-element.html on Windows.
Also, mac doesn't pass this test because MOZ_BUNDLED_FONTS isn't set on macOS build.
MozReview-Commit-ID: 5ylfn8525j7
--HG--
extra : rebase_source : 9e894b4edea52a75c9a13c523679039d7ef0d59c
Ahem.ttf is copied to $(DIST)/bin/firefox/fonts, but this file is broken due to text mode copy. So we should use binary mode instead.
MozReview-Commit-ID: KP7yNyPiejU
--HG--
extra : rebase_source : 2de749f458a6d4650f9044f1912ff97835c5b795
The lesson learned from bug 1356926 and bug 1386588 is that the version
of gcc used to build clang matters, and that we can't bind the version
we use to build clang to the version we use to build Firefox.
In some cases, we can end up linking some things with
--static-libstdc++. The notable (only?) example of that is for the
clang-plugin, and that happens because it gets some of its flags from
llvm-config, which contains --static-libstdc++ because clang itself is
built that way.
When that happens, the combination of --static-libstdc++ and
stdc++compat breaks the build because they have conflicting symbols,
which is very much by design.
There are two ways out of this:
- avoiding either -static-libstdc++ or stdc++compat
- work around the symbol conflicts
The former is not totally reliable ; we'd have to accurately determine
if we're in a potentially conflicting case, and remove one of the two in
that case, and while we can do that for the cases we explicitly know
about, that's not future-proof, and might fail just as much in the
future.
So we go with the latter. The way we do this is by defining all the
std++compat symbols weak, such that at link time, they're overridden by
any symbol with the same name. When building with -static-libstdc++,
libstdc++.a provides those symbols so the linker eliminates the weak
ones. When not building with -static-libstdc++, the linker keeps the
symbols from stdc++compat. That last assertion is validated by the
long-standing CHECK_STDCXX test that we run when linking shared
libraries and programs.
That still leaves the symbols weak in the final shared
libraries/programs, which is a change from the current setup, but
shouldn't cause problems because when using versions of libstdc++.so
that do provide those symbols, it's fine to use the libstdc++.so version
anyways.
This method can be extremely hot, so we need to remove all sources of XPCOM
overhead from it. This includes the usages of weak pointers (thanks to the
previous parts), refcounting, and QueryInterface.
I kept the callers hold the selection controller alive by assigning the
return value to an nsCOMPtr in places where the methods called on it could
have a remote chance of messing with the lifetime of objects.
We need to create a WebRenderAnimationData item in order to preserve the
animation id on the frame - this allows to re-use the same animation id
over multiple display list building phases.
MozReview-Commit-ID: 5Uj5sv6FUgt
