Make it always forward to the document's docshell. We rely on it being setup by
the time our stuff runs, and we cannot have multiple pres contexts per document
in different docshells anymore.
This allows me to also move some state to the document (about whether it's
currently loaded in a chrome docshell (nsPresContext::mIsChrome) and whether
it's a chrome origin image (nsPresContext::mIsChromeOriginImage), which will
help for bug 1490401 / bug 1418159.
The pres context already relies on having the docshell available on `Init` and
we don't properly handle dynamic changes to it.
The reason I store some state like whether the doc URI is chrome:// and whether
we're in a chrome docshell is not (only) to avoid recomputing it over and over,
but also to allow me to read them from Stylo (main-thread blocked, but poke at
that from multiple non-main-threads).
Differential Revision: https://phabricator.services.mozilla.com/D20301
--HG--
extra : moz-landing-system : lando
On integrated GPUs, we are typically completely bound by memory
bandwidth and the number of pixels that get written / blended.
On real world pages, it's often the case that we end up with
clip tasks that are long in one dimension but not the other, due
to box-shadow edges, clip mask segments etc. When this occurs,
the logic that tries to get a small 'used_rect' to clear targets
to fails, since the union of those ends up being a very large
rect that covers (most of) the surface. This can cost a lot of
GPU time on some integrated chipsets.
Instead, it appears to be much faster to issue multiple clears,
one for each clip mask region, which is typically < 10% of the
surface we were clearing previously.
However, we can also restore an old optimization we used to have
which means we can skip clears altogether in the common case. The
first mask in a clip task will write to all the pixels in the mask,
so we can draw that with blending disabled (also a significant win
on integrated GPUs) and skip the clear in these cases. With this
functionality in place, the multiplicative blend mode is only
enabled for any clips other than the first in a mask (this is
quite a rare case - most clip tasks end up with a single mask).
On low end GPUs driving a 4k screen, I've measured GPU wins of up
to 5 ms/frame on some real world pages with this change.
Differential Revision: https://phabricator.services.mozilla.com/D19893
--HG--
extra : moz-landing-system : lando
Fix loading of empty JSON dump
Storing an empty JSON dump should prevent .get() to initiate a sync.
Differential Revision: https://phabricator.services.mozilla.com/D20352
--HG--
extra : moz-landing-system : lando
In bug 1470918, a shared thread was introduced that did the reading/writing work
for all DataStorage instances. To ensure all state was written out at shutdown,
the original patch implemented a two stage strategy that in the first stage
queued an event for each DataStorage that would write out its contents and then
in the second stage ran these events to completion. This conflicted with how
Firefox's sanitization implementation would make sure that data was cleared at
shutdown, if requested by the user. If the DataStorage objects observed the
first shutdown notification before the sanitization implementation, the existing
data would be queued for writing and any further updates would be prevented.
Thus, when the sanitizer tried to clear data held by DataStorage instances,
nothing would happen and the data would be written to disk.
This patch fixes this issue by implementing DataStorage shutdown in a single
stage that can run after sanitization. Since sDataStorages knows of the
existence of every DataStorage, we can simply iterate through its entries, queue
write events for each one, and then run those events to completion in one pass.
This patch also fixes bug 1528019 (gDataStorageSharedThread could leak if
NS_NewNamedThread failed) because the fix is trivial and not worth handling in
an entirely separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D20034
--HG--
extra : moz-landing-system : lando
Include a boolean reporting whether these prefs are enabled on startup. inlcude extra information when user interacts with the control panel reporting if anything is being blocked.
Differential Revision: https://phabricator.services.mozilla.com/D19843
--HG--
extra : source : 8ae2da51010e64e1c0a970acb0d2182796635f82
extra : histedit_source : d18fdb19d6dc58e83b32b50e1a468f6558842627
