We maintain a simple LRU cache of tab layers by setting their
docShellIsActive = false with preserveLayers(true). Once they
are pushed out of the cache by more recently used tabs, their
layers are discarded.
Luckily most of the complexity of this could be contained in
the AsyncTabSwitcher - the one change that had to sit outside of
that was moving the aTab.closing = true earlier in the removeTab
call, so that we could use that information to eagerly evict tabs
from the cache. This was to address a leak in a few tests on try.
MozReview-Commit-ID: 2E3uU8LEYkD
--HG--
extra : rebase_source : b7e7bb3fcf1ed59e79a7c9fb9d3e6ce735ab54e9
We maintain a simple LRU cache of tab layers by setting their
docShellIsActive = false with preserveLayers(true). Once they
are pushed out of the cache by more recently used tabs, their
layers are discarded.
Luckily most of the complexity of this could be contained in
the AsyncTabSwitcher - the one change that had to sit outside of
that was moving the aTab.closing = true earlier in the removeTab
call, so that we could use that information to eagerly evict tabs
from the cache. This was to address a leak in a few tests on try.
MozReview-Commit-ID: 2E3uU8LEYkD
--HG--
extra : rebase_source : b7e7bb3fcf1ed59e79a7c9fb9d3e6ce735ab54e9
We maintain a simple LRU cache of tab layers by setting their
docShellIsActive = false with preserveLayers(true). Once they
are pushed out of the cache by more recently used tabs, their
layers are discarded.
Luckily most of the complexity of this could be contained in
the AsyncTabSwitcher - the one change that had to sit outside of
that was moving the aTab.closing = true earlier in the removeTab
call, so that we could use that information to eagerly evict tabs
from the cache. This was to address a leak in a few tests on try.
MozReview-Commit-ID: 2E3uU8LEYkD
--HG--
extra : rebase_source : 1de7c196b14b2f3a368bfbae970808cbf49e6e36
It looks like TabChild::RenderLayers already does the work of suppressing the displayport,
so all of the suppression and bookkeeping that AsyncTabSwitcher is doing is superfluous
and probably opening us up to weird graphical glitches (like the one associated with this
bug).
MozReview-Commit-ID: 5qIVguSMsnr
--HG--
extra : rebase_source : 59e72715791cb8aa25310e48b5a02e1b86762543
It looks like TabChild::RenderLayers already does the work of suppressing the displayport,
so all of the suppression and bookkeeping that AsyncTabSwitcher is doing is superfluous
and probably opening us up to weird graphical glitches (like the one associated with this
bug).
MozReview-Commit-ID: 5qIVguSMsnr
--HG--
extra : rebase_source : 35f944a324415401c4a28ed0006baf9361ef73c8
We suppress the displayport when requesting a tab or warming it, in order to reduce
the amount of work that the content process needs to do to paint it (we paint just
the displayport area and nothing around it). Afterwards, we unsuppress the displayport
so that we can paint the surrounding areas when scrolling. We normally do this
unsuppression in destroy(), but with tab warming, that unsuppression can happen
after a few seconds (after the tab warming eviction timeout).
This results in users seeing checkerboarding sometimes, where the tab they're looking
at is still suppressing its displayport and waiting for the timeout to complete.
This patch updates the AsyncTabSwitcher to unsuppress the displayport for a tab as
soon as the tab has been switched to, instead of waiting for the timeout.
Out of an abundance of caution, we still unsuppress displayports for tabs that
never get to enter the STATE_LOADED state, although that really should never
happen.
MozReview-Commit-ID: 5qIVguSMsnr
--HG--
extra : rebase_source : 90c0d617ac3d43a8d4513e864ba2f0a3228a5582
Since bug 1432509, the warmingTabs WeakSet has had warmed tabs
cleared from it once they have entered STATE_LOADED. This allowed
us to make decisions on tab switch operations based on whether or
not a tab was still being warmed.
This broke our Telemetry, which assumed that warming tabs would
still be in the warmingTabs WeakSet until either requested or
evicted. Now, instead, we look to see whether or not tab warming
is enabled, and whether tabs _could_ have been warmed in order to
add entries to the right buckets.
MozReview-Commit-ID: 94oiKYzf4au
--HG--
extra : rebase_source : 0b6be98ff93d9753fcdacbec15a2a7b08232bb3a
