This implements the following three things:
- use the frame callback timestamp. While there are few guarantees about
its behaviour, it still seems to make sense to use it assuming: a) the compositor
uses monotonic system time (we do a simple sanity check) b) the compositor is
more likely to run at high priority, thus making the offset from the actual
vsync less jittery c) the timestamp is closer to the actual vsync event,
making it more fitting for how we use it internally
- implement a very simplistic estimate of the refresh interval.
Since bug 1653737 WR takes an estimated next output time to optimize
for. Until now this was hardcoded to 16.6ms from the last `Now()`. Now
we adjust the value on each interval slightly, making it much more
precise on non-60Hz refresh rates (this certainly can get improved more)
- Shuffle around mutex looking a bit, making sure we don't hold it
while calling `NotifyVsync()`. That should make it less likely to run
into deadlock conditions.
Depends on D95515
Differential Revision: https://phabricator.services.mozilla.com/D93169
Our fract offset for the tiles should be a simple mapping of the snapped
device position back to picture space. If no snapping is required, then
the position will be precisely the origin. When using this value to
decide if the position has changed for glyph subpixel offset purposes,
we must consider it in device space, since picture to device space can
be effectively arbitrary.
We update the stored fract offset at which a tile was rendered whenever
we invalidate the whole tile, not just when we detect the fract offset
has changed by a notable amount. This should reduce spurious
invalidations since the tile was actually rendered at a different offset
that we had recorded prior to this patch.
Differential Revision: https://phabricator.services.mozilla.com/D91156
This patch makes use of the new "Baldrdash2020" ABI support in Cranelift
to support the "ABI 2020" refactor in the Wasm compiler.
Differential Revision: https://phabricator.services.mozilla.com/D93190
Here we remove remaining uses of Frame::tls. There are many places where
we use it: in debug frames, in profiling frames, in jit activation, etc.
All these places require short fixes to use our new scheme for getting
tls, so I gathered them together.
Differential Revision: https://phabricator.services.mozilla.com/D83051
Here we replace usage of Frame::tls in frame iteration with GetNearestEffectiveTls.
We also maintain current tls for frame iteration object to not to call GetNearestEffectiveTls everytime.
Differential Revision: https://phabricator.services.mozilla.com/D83045
This is the third part of series of patches to Frame without tls pointer.
Here we preserve initial tls in all entry stubs and then use it to find a proper tls instance for a given frame.
To find the TlsData* for specific frame we start from a entry stub's tls
and then track tls through all possible cross-instance calls. This logic
is implemented in GetNearestEffectiveTls procedure.
Then, we use this new procedure to make singal handling free from Frame::tls.
Differential Revision: https://phabricator.services.mozilla.com/D83044
This is a followup patch for removing Frame::tls.
Now, we are preserving caller's and callee's tls'es for all possible cross-instance calls in the previously allocated abi slots.
We also use preserved tls values to restore the caller's tls in Ion. Baseline doesn't need this because it restores the caller tls from its private stack slot after the call.
Differential Revision: https://phabricator.services.mozilla.com/D82888
We are going to remove Frame::tls and support trampolines for indirect calls, so we need to get rid of using Frame::tls.
In this and the followup patches I will iteratively remove all dependencies of Frame::tls and remove it eventually.
In this patch I changed wasm ABI to allocate two stack slots after stack args to preserve caller's and callee's tls'es in the near future.
Differential Revision: https://phabricator.services.mozilla.com/D82881
Include the HashNumber in XDR data so we don't need to recompute it and can
speed up interning of these known-to-be-unique ParserAtoms.
Differential Revision: https://phabricator.services.mozilla.com/D95466
We currently assert that XDR'd ParserAtoms are unique, but still use the
slightly slower lookupForAdd APIs. Instead, the patch uses putNew which
avoids an extra comparison on hash collisions.
Also greatly simplify the Char16LE case which is only used for XDR and can
safely assume no static strings or non-wide atoms are passed.
Differential Revision: https://phabricator.services.mozilla.com/D95465
Now that XDR checks for correct endianness, we can use codeBytes for more
complex structures. We also move the function to StencilXdr namespace.
Differential Revision: https://phabricator.services.mozilla.com/D95587
Allow autofill to fill partial search providers domains so that, for example,
en.wikipedia.org can be filled by typing "wiki".
Differential Revision: https://phabricator.services.mozilla.com/D95277
- add allowHttp3 attribute to nsIHttpChannelInternal, it is used for easy testing and it will be used for Bug 1674111
- add test for NS_HTTP_DISALLOW_HTTP3 and NS_HTTP_DISALLOW_SPDY
- add HTTP3 test for altSvc and the cert verifiacation
Differential Revision: https://phabricator.services.mozilla.com/D95256
Wayland protocol does not include a mechanism how to inform compositor about deleted frame callbacks.
We delete a callback only locally on client side and it remains active at server (compositor) side.
When large amount of callbacks is accumulated at server Firefox is closed due to OOM
so we need to keep frame callback on local side untill is fired and don't create a new one.
Differential Revision: https://phabricator.services.mozilla.com/D95678
I'll need to update this file for clang-12, and in order to prevent the need for adding more of these ifdefs, let's just assume they are true and remove the checks. Our codebase has been on C++17 for a while now.
Differential Revision: https://phabricator.services.mozilla.com/D95592