Notice as TimeStamp is not an integral type, it can't be wrapped by
mozilla::Atomic. However, we wrap it in MainThreadData to assure it only
is accessed from the main thread.
Another issue is that TimeStamp class does allow some operations on a
Null value, with assertions on debug builds.
MozReview-Commit-ID: 9GPNDUooQmI
--HG--
extra : rebase_source : e2b5fe81a4c5c696425583a04395f2ae79aeaccc
window.event is set on the wrong window when the target and the
callback are from different realms and the callback is an XPCOM
callback.
MozReview-Commit-ID: HXeUIicdMuT
--HG--
extra : rebase_source : 978a3fecf87e1ac4414ec0ea93335796bc24951a
The new pref is "network.dns.resolver-thread-extra-idle-time-seconds"
The default is 60 seconds. This means that threads will stay idle for an extra 60 seconds, after which they are shutdown.
Setting the pref to 0 would preserve the behaviour before the threads were swiched to use nsThreadPool - meaning that they would be shutdown immediately after ThreadFunc completes.
Setting the pref to -1 would keep the threads alive forever.
MozReview-Commit-ID: CoUB5gan4MR
--HG--
extra : rebase_source : 7b444789eebaf43c939ce9d7153218c4cd594b65
Instead of creating and deleteing each thread, we use a nsThreadPool with a max of 8 resolver threads.
Whereas before each thread would run ThreadFunc exactly once then shut down, the threads may now remain active for a while. During this time we may post another task(runnable) to the thread.
MozReview-Commit-ID: FiE370ic1ah
--HG--
extra : rebase_source : 065bbf1f9867dfb38ac7b13816d4d06824d3a05d
This reduced the additional string duplication that we currently do every time
we add a preference observer.
It changes the string that we store in the observer objects to be absolute,
rather than relative to the branch, but keeps the semantics the same, by
resolving the full preference name in the places we were previously matching
by relative string.
This actually has the effect of simplifying a lot of code, since the absolute
preference name is usually what we want.
MozReview-Commit-ID: 10WjHb0tNGB
--HG--
extra : rebase_source : b3cb0ba103fc239e42459e77cd389db0b5ecde18
Most preference callbacks use literal strings for their domain filters, which
means that there's no need to make copies of them at all. Currently, however,
every preference observer node makes a separate heap-allocated copy of its
domain string.
This patch switches the domain string storage to nsCString instances, which
dramatically reduces the amount of unnecessary copies, at the expense of
making the callback nodes slightly larger.
MozReview-Commit-ID: 8NA3t2JS2UI
--HG--
extra : rebase_source : 628ad9af65cec16fb8be0c8dddc608b5ee5602e2
There seem race conditions that we do a paint process when we started observing
the refresh driver but the first tick hasn't happened yet.
MozReview-Commit-ID: KRP8WR644q1
These cause us to load Console.jsm and create a ConsoleAPI instance in every
content process, which is expensive both in terms of memory and startup
performance.
Checking the log level before we touch the console object is much cheaper,
in terms of both memory and performance.
MozReview-Commit-ID: 19f0ggAda2J
--HG--
extra : source : 440ee3fab72afc5d483a5bb2b0630f3c2ed3212f
extra : absorb_source : 35ba172bb0e9da002bf1b733463b61ed214cf225
These cause us to load Console.jsm and create a ConsoleAPI instance in every
content process, which is expensive both in terms of memory and startup
performance.
Checking the log level before we touch the console object is much cheaper,
in terms of both memory and performance.
MozReview-Commit-ID: 19f0ggAda2J
--HG--
extra : rebase_source : 38077a14122d201d11079330565d82f6f963b428
This call was added in bug 929362, but the key factor to fix the bug was just
setting a flag representing that the target frame doesn't allow the animation
running on the compositor and checking the flag in the function whether the
animation can be run on the compositor or not in later ticks. So the call
wasn't necessary in the first place.
The test case here fails without this fix. The test case actually doesn't
observe animation restyle count at all, so it might look a bit awkward in
file_restyles.html, if we add other test cases checking SchedulePaint calls
in future, we will move the tests in a different file.
(The reason there is no animation restyles in this case is that we properly
throttle the animation in this case.)
MozReview-Commit-ID: AyHciRJHM0s
--HG--
extra : rebase_source : f3963336ea9165b0a9c1a662bdac5c645b209219
Take AutoSaveLiveRegisters as an argument, and use that to ensure the registers were saved
--HG--
extra : rebase_source : bb54592bd009afc67aaa0ca9c705ab28f4a45d44
Automatic update from web-platform-testsClean up budget-api idl test (#11445)
Follow up for #9763 now that #10338 is resolved and we have #10381 too.
--
wpt-commits: 7b2cd8b78d938ea8879adc6419f2ea14b6af8bad
wpt-pr: 11445
