If we can assume that a layer being composited has an APZC at index i if and
only if the frame metrics at index i is scrollable, then we can do the
transformations in the next patch without any change in functionality.
MozReview-Commit-ID: FRkvhwdd3nh
--HG--
extra : rebase_source : f1bee292305730079b3208e447330028c1a40727
This makes more sense in APZCTreeManager, but is exposed back to
AsyncCompositionManager via APZSampler. This also makes the APZ code
better encapsulated since the method API exposed on APZSampler doesn't
need to take a AsyncPanZoomController; it can just take the
LayerMetricsWrapper instead.
MozReview-Commit-ID: 9yJJd3x8VhN
--HG--
extra : rebase_source : b6f81116183810df158d8cce72891bb2db458355
Before, we would initialize LRUCache on the first instance of
calling the Timer Precision Reduction functions. We would both
allocate and initialize it, and call ClearOnShutdown.
ClearOnShutdown can only be called on the Main Thread, but it
just so happened that we always did that, so there was no
problem. Now that we are not calling precision reduction for
system callers, we were initializing on a non-main-thread and
we need to avoid that.
In the future, we could reduce memory use IF we are not using
the timer precision reduction functions by figuring out how
to initialize this lazily but still on the main thread. For
now, because we are using the timer precision reduction
functions, doing so would not save us any memory.
MozReview-Commit-ID: 6YGeAlCPReZ
Because plugin state in the content now contains blocklist state, and is updated
when the blocklist updates, we don't need to ask the parent if we're checking
blocklist state. All the consumers should now be asking the plugin code directly,
so we can stub out the last API here. We should look at removing the content side
of this service entirely, but that's something for a follow-up bug.
MozReview-Commit-ID: DE8s8RwT42r
--HG--
extra : rebase_source : 06fbc304e99679f55c7cdc52404cd138221feca3
This changes the pluginreg.dat format to include the blocklist state.
There is now only the saved blocklist state in a plugin tag instance, rather than
looking it up from in there using the blocklist service, so it was renamed from
mCachedBlocklistState to mBlocklistState. We pass the 'right' state to the plugin
instance when the plugintag is constructed. If we don't have state, we mark it as
unblocked.
mCachedBlocklistStateChanged was never read so it's being removed.
Bug 1439519 adds a 'blocklist-loaded' notification that is fired once the blocklist is loaded.
The plugin host implementation will listen to this in the parent process and update the
blocklist state of all the plugins, and broadcast changes to the child process, just like when
we update the blocklist from the server. We now also avoid re-sending plugin content to the
content processes if the plugin state hasn't changed as a result of the blocklist having been
loaded.
Finally, because new plugins should still get an up-to-date blocklist state, and
telemetry should get up-to-date data about which plugins are and aren't enabled
once we have that data, we ensure that once we've loaded the blocklist async,
we schedule an idle task to parse it and consider it loaded.
All this means that plugin blocklist information could be mistaken between the points where
a new plugin is installed and we first run Firefox with the new plugin, and the point where
we load the blocklist. Given the trade-offs, that size of window (tiny) seems OK, also given
that there's already a much larger window in blocklist updates (which only happen once every 24h).
MozReview-Commit-ID: 1gsojRkUzTw
--HG--
extra : rebase_source : 4709916b4674ada54f8a495fd2d16fcef8c58d20
We use a wrapper script when compiling with MSVC to parse the
/showIncludes output and thereby generate a Makefile dependency
fragment. This fragment enables us to do correct and faster incremental
builds. But the cost of invoking the wrapper script can be significant;
it's an extra process or two to launch for every single compilation.
Instead, let's have clang-cl generate the dependencies directly, which
should be somewhat faster.
When we fail to generate an image key for an image, it is likely because
the image container is empty. This is not a fatal error, it just means
we haven't produced a frame yet. We should be using NOT_READY instead of
BAD_IMAGE as a result. This is important because reftests rely upon
these error codes to know whether or not they should wait; it could
cause intermittent failures.
If an image container is empty, it will not produce an image key for use
with WebRender. This is generally not a sign of failure because the
producer likely has yet to populate the container with data. As such, we
should not immediately attempt to fallback. In fact, fallback can make
things worse in this situation, as we will create an image client to
send over the data, but then find that there is no data to share (or
find that there is, due to a race with the producer thread, and use
image clients when we could use shared surfaces).
Summary: It uses two node bits that can be better suited for something else.
Reviewers: xidorn, smaug
Bug #: 1444905
Differential Revision: https://phabricator.services.mozilla.com/D709
MozReview-Commit-ID: HIPDtHm6xpM
