All animated images on a page are currently registered with the refresh
driver and advance with the tick refresh. These animations may not even
be in view, and if they are large and thus cause redecoding, cause a
marked increase in CPU usage for no benefit to the user.
This patch adds an additional flag, mCompositedFrameRequested, to the
AnimationState used by FrameAnimator. It is set to true each time the
current animated image frame is requested via
FrameAnimator::GetCompositedFrame. It is set to false each time the
frame is advanced in FrameAnimator::AdvanceFrame (via
FrameAnimator::RequestRefresh). If it is true when
FrameAnimator::RequestRefresh is called, then it will advance the
animation according to the normal rules. If it is false, then it will
set the current animation time to the current time instead of advancing.
This should not cause the animation to fall behind anymore or skip
frames more than it does today. This is because if
FrameAnimator::GetCompositedFrame is not called, then the internal state
of the animation is advancing ahead of what the user sees. Once it is
called, the new frame is far ahead of the previously displayed frame.
The only difference now is that we will display the previous frame for
slightly longer until the next refresh tick.
Note that if an animated image is layerized (should not happen today) or
otherwise uses an ImageContainer, this optimization fails. While we know
whether or not we have an image container, we do not know if anything is
actively using it.
Summary:
In essence, we're allowing a new field in the task definition,
which is trusted over the one that's passed in with the config. This
wouldn't make much sense if it had a real date in, but allows us to
set an empty string for the kind that needs it
Reviewers: bhearsum
Reviewed By: bhearsum
Bug #: 1458854
Differential Revision: https://phabricator.services.mozilla.com/D1214
--HG--
extra : rebase_source : 82145a94fa91957ffe57112a1c0d327d99e32b23
On Desktop and GeckoView we only ever need to store histograms for a
subsession and clear the histograms when a snapshot is done (e.g. a main ping is built).
On Fennec we don't have subsessions and only store for a session and never clear the storage.
MozReview-Commit-ID: BeVi86kZPs2
--HG--
extra : rebase_source : 50bb218c9fb9a04c8d60d6300e4e9e67544232c0
Unfortunately, FileAvoidWrite causes us to re-generate .xpt files every time we
build if a dependency of the .xpt files doesn't affect their output.
The easiest solution is to stop performing this option until we get a better
build backend like `tup` which can handle problems like this.
Currently stringbundle.js is loaded in response to the document-element-inserted message
in MainProcessSingleton. But since the profile manager loads before that script is run,
we don't register the Custom Element. This fixes that by explicitly including the script.
MozReview-Commit-ID: GqQk1VUv0Df
--HG--
extra : rebase_source : 1d958661865591b3e4260d566f83c5eb16bfa1b5
Experimentally try using a String literal in case the NullPointerException at
that line is caused by some weird class initialisation issue.
MozReview-Commit-ID: 1BexpntTBEJ
--HG--
extra : rebase_source : ea71f390ce0d683cd635aae52825871562b78feb
This serves two purposes:
1) It makes web-platform-tests pref downloading/handling a little more robust. When
run externally, it now downloads the entire testing/profiles directory. When loading
prefs it will look for both prefs_general.js (to support older versions of Firefox)
and profiles.json (for support moving forward).
This way we can add/remove/rename pref files under these directories without needing
to worry about breaking upstream wpt.
2) It provides developers an overview of which harnesses are using which base profiles.
Instead of hunting through test harness code to find this information, they can glance
at profiles.json.
MozReview-Commit-ID: AMzdnD8aGA2
--HG--
extra : rebase_source : 6fa0a802680417e49fcef99f3d03de7458a8fcba
With the fix on bug 1449538 the shutdown hangs which have caused the
timeout errors are gone. So we can safely re-enable the tests.
MozReview-Commit-ID: 4XTRQtwwRZd
--HG--
extra : rebase_source : 6b94222198922f6c85a36b3bc3e70bb8b7b0f461
NPAPI may handle a 307 redirect across different origins, while they
should only happen on same origin requests. Have the browser check
this before forwarding to NPAPI.
MozReview-Commit-ID: 5vxMooygI4g
--HG--
extra : rebase_source : 36ab35b389c1746bbfd3482ff68b81bac34e4de1