This patch is going to loose the criteria of skip-to-next-key-frame.
The original rules are here:
http://searchfox.org/mozilla-central/rev/31311070d9860b24fe4a7a36976c14b328c16208/dom/media/MediaFormatReader.cpp#1559
Skip-to-next-key-frame is triggered if the playback position is LARGER than the next key frame time.
But, from the video-track point of view, when the skip-to-next-key-frame is triggered, it skips to the next-next key frame.
Here is an example, say, we are playing a media file with its playback position at time _a_,
and its video decoding is falling behind at time _v_.
The next key frame is at time _k1_ and next-next key frame is at time _k2_.
a
----|---------|---------|-------------|----------------> time
v k1 k2
When the playback position _a_ passes _k1_ (_a_ > _k1_), the skip-to-next-key-frame is triggered,
and the demuxer jumps to _k2_ directly.
The idea here is to give a chance when (_a_ == _k1_), let demuxer jump to _k1_ and see if the video decoding could catch up.
MozReview-Commit-ID: 6aRSYDOI1ds
--HG--
extra : rebase_source : c448df7af9f83b9127bad9bae28f353b40669b7f
We found that a window will not get focus immediately after exiting full screen
mode on Linux. This seems to be a long-standing issue which surfaces due to the
change of background HTML parsing timing. So, we try to get focus everytime
before requesting full screen mode to ensure the request will not fail because
of the focus issue.
MozReview-Commit-ID: 2pOShFZcq8A
--HG--
extra : rebase_source : a92fad6a5e31e7387824da42ef2655a0f7ba002f
This patch is mainly to make IdleTaskRunner reusable by nsHtml5TreeOpExecutor.
The only necessary work to that purpose is to remove the dependency of
sShuttingDown, which was a static variable in nsJSEnvironment.cpp.
The idea is to have a "ShouldCancel" as a callback for the consumer to
return sShuttingDown.
In addition to sShuttingDown, we use std::function<bool()> as the runner
main callback type.
MozReview-Commit-ID: FT2X1unSvPS
--HG--
extra : rebase_source : dc9bcf669a95dda5c40bccde2cbc836099536eb5
Nothing is changed in this patch except for renaming and code move around.
The strategy is to have the final file setup in this patch without any
detail change. The actual code change will be in the next patch so that
we can focus on reviewing the diff in the next patch regarding IdleTaskRunner.
MozReview-Commit-ID: 4Bul9mZ7z1n
--HG--
extra : rebase_source : 22aeb5dca58501ec335ef8bc7b0efb6aea565bbf
Before this refactoring, getComputedStyle could have side effects, and left the
style data in the element, so we could never arrive there without data.
There are a few crashtests that caught this, but this was already broken if you
called animate() on an element deep in a display: none subtree.
MozReview-Commit-ID: 1AvOvhAyOP3
--HG--
extra : rebase_source : 0a920df8809961f784026a14a624d8eafb4cc79f
The previous patch takes the approach that we should simply not add elements in
documents without a pres shell to EffectCompositor's set of elements to restyle.
However, there exists a case where we might have an element in a displayed
document, then we might tickle it so that it requests an animation restyle, and
then move it to a document without a browsing context. In that case we should
skip the element when we next do animation restyles.
However, even if we successfully skip the element in the document without a pres
shell, we need to make sure it eventually gets removed from the set of elements
to restyle rather than simply remaining there forever. For that reason this
patch makes us unconditionally clear the set of elements to restyle whenever we
do a full restyle from the root.
This patch also adds a test case to trigger the scenario outlined in the first
paragraph above. I have confirmed that without the code changes in this patch,
if we simply assert that target.mElement has an associated pres shell in
getNeededRestyleTarget, then that assertion will fail when running this test
case.
MozReview-Commit-ID: ED2X5g39hYZ
--HG--
extra : rebase_source : 06fecc98c25c739d26123bddf1fd0908cf4410e6
extra : source : 12c7a036215a901bf6804c0e9aacd2a9fc20f932
This patch makes us ignore animation restyle requests for elements in documents
without a pres shell made by either:
* Calls to EffectCompositor::RequestRestyle (e.g. by calling Web Animations API
methods on animations that target such elements)
* Calls to EffectCompostior::PreTraverse(dom::Element*, CSSPseudoElementType)
(e.g. by calling getComputedStyle(elem).prop on such an element).
The other overloads of PreTraverse should presumably be called during regular
document restyling where the element is expected to be in a displayed document
and hence we simply assert that that is the case for those methods.
MozReview-Commit-ID: FZD0hKAXYEf
--HG--
extra : rebase_source : 9b9ddf4648b49e0241054ffa51a02ae66f1c5009
This combines the GhostWindowsReporter with the nsWindowMemoryReporter. It has
the benefit of removing a reporter of a single value and also guarantees that
we use the latests ghost windows value that is calculated in
|nsWindowMemoryReporter::CollectReports| rather than a possibly cached value
from a previous run.
Avoid hitting the rather slow effective TLD service by caching results when
mapping URLs to their base domains. In testing the cache ranged from a 1:1 to
a 3:1 hit:miss ratio.
We already periodically calculate the ghost window amount after cycle
collection, this just uses a cached value of that for the distinguished amount.
This avoids the overhead of a recalculating the value when reporting telemetry.
We should not let the ppm to do work before the first paint in a new cp. This patch
makes sure that we only let the ppm spawn a new process after the last process reached
an idle state AND the main process becomes idle too.
The main reason to not do this would be performance (avoiding the
addref/release), but there are two main mitigating factors:
1) All calls to UnwrapReflectorToISupports that pass in a Web IDL object
already do the addref (and in fact QI). So this only affects the
XPCWrappedNative case.
2) The vast majority of the callers proceed to QI on the pointer anyway, and a
second addref is cheap; it's the first addref after a CC that can be
expensive on a cycle-collected object.
Going through the changes one by one:
* In GlobalObject::GetAsSupports, we do have a change that slightly slows down
precisely in the XPCWrappedNative global case. That's the message managers
and the backstagepass. And this really only affects calls to Web IDL statics
from those globals.
* In UnwrapArgImpl we're talking about a Web IDL method taking an "external
interface" type, and the UnwrapReflectorToISupports call is immediately
followed by QI anyway.
* In UnwrapXPConnectImpl we're talking about the case when we have a
non-WebIDL-object implementation of a Web IDL interface. Again, this is the
message manager globals, for EventTarget. And we have a QI call immediately
after the UnwrapReflectorToISupports.
* In the generated HasInstance hook for EventTarget we will be slightly slower
when the LHS of the instanceof is an XPCWrappedNative. And not much slower,
because again there's an immediate QI.
* In InstallXBLField we're never going to have an XPCWrappedNative as thisObj;
it's always an Element in practice. So this is no more expensive than before.
* In sandbox's GetPrincipalOrSOP we now have an extra addref. But it was
followed by various QIs anyway.
* In XPCConvert::JSValToXPCException we have an extra addref if someone throws
an XPCWrappedNative, which is fairly unlikely; our actual Exception objects
are on Web IDL bindings. Plus we have an immediate QI.
* In xpc::HasInstance we have an extra addred if the LHS of instanceof is an
XPCWrappedNative. But, again, there's an immediated QI after the
UnwrapReflectorToISupports.
* In xpcJSWeakReference::Init we are likely doing an extra addref, but again
immediately followed by QI.
I think it's worth making this change just to remove the footgun and that the
perf impact, if any, is pretty minimal.
Most of these changes are just replacements of GetNativeOfWrapper with
UnwrapReflectorToISupports, which is all it did under the hood.
The other changes are as follows:
* In nsDOMClassInfo, we really care whether we have a window, so we can just
UNWRAP_OBJECT to the Window interface, since Window is always on Web IDL
bindings now. Also, the weird compartment check hasn't been needed ever since
GetNativeOfWrapper stopped returning things off the passed-in object's
prototype chain (Firefox 22, bug 658909).
* The only use of do_QueryWrapper was to get a Window in nsDocument; again we
can UNWRAP_OBJECT.
* In XPCJSRuntime, we again just want to check for a Window, so UNWRAP_OBJECT.
The idea is that CastableObjectUnwrapper will want to have a MutableHandle for
the thing it's unwrapping whenever its target is a raw pointer. Since we have
convenient MutableHandle<Value> in most cases, it's easier to switch
CastableObjectUnwrapper to working with MutableHandle<Value> or Handle<Value>
instead of trying to get MutableHandle<JSObject*> in the right places.
There are basically two changes here:
1) Make CastableObjectUnwrapper work with at thing that looks like a Value.
2) Change various callsites to pass in MutableHandle<Value>, in addition to a
Handle<Value>, into the JS-to-C++ conversion templates. The
MutableHandle<Value> is passed as ${maybeMutableVal}. It may not actually
end up being a MutableHandle in some cases.
The reason for passing both a Handle and a MutableHandle is that when the thing
we actually have is a Rooted named "foo" the Handle will be "foo" but the
MutableHandle is most naturally written as "&foo". This is not a problem if
you're just passing it through, but if you want to test whether it's an object,
say, you have a problem. Writing "foo.isObject()" is ok, but "&foo.isObject()"
is not, and neither is "(&foo).isObject()". This could be worked around by
passing the MutableHandle as "JS::MutableHandle<JS::Value>(&foo)" or something,
and then "JS::MutableHandle<JS::Value>(&foo).isObject()" does work. But it
makes the code very hard to read.
So we just pass both things along; ${val} should be used for readonly access and
${maybeMutableVal} any time you really want a MutableHandle.