The previous `js::powi` implementation could cause large floating point
precision errors. For example `(-1.00000041289256280663266807096078991889953613281250000) ** -365287834`
returned `3.1456398721089196e-66` instead of `3.1456398910784315e-66`. This is an
error of 35987774 ULP.
Change `js::powi` as follows:
- Optimise only for non-negative exponents.
- Always optimise when the exponent is `<= 4` to match `MPow::foldsTo`.
- When the exponent is `> 4`, only optimise when the base is an integer. Perform
the whole computation with integer values and when an overflow was detected,
fallback to `std::pow`.
- In all other cases use `std::pow`.
Differential Revision: https://phabricator.services.mozilla.com/D150791
Adding `StringBuffer::append(std::string_view)` would make this more readable,
but the implicit `std::string_view(char*)` constructor could then lead to adding
implicit `strlen` calls, which we try to avoid.
Differential Revision: https://phabricator.services.mozilla.com/D152047
builtin/Object.cpp:
- Using `string_view` avoids the call to `strlen` when `Consume` isn't inlined.
jsapi-tests/testCompileNonSyntactic.cpp:
shell/jsoptparse.cpp:
xpconnect/src/XPCWrappedNativeJSOps.cpp:
- Using `string_view` avoids the `sizeof - 1` pattern.
Depends on D152044
Differential Revision: https://phabricator.services.mozilla.com/D152045
`std::string_view` stores a pointer and its length, so we no longer have to
use two different variables. `std::string_view` methods are also `const_expr`,
so the compiler will inline them at compile-time.
Depends on D152043
Differential Revision: https://phabricator.services.mozilla.com/D152044
Part 1 ensures we generate fast code when comparing against constant `char*`
strings, so we no longer need the more complicated code.
Depends on D152042
Differential Revision: https://phabricator.services.mozilla.com/D152043
This makes the code a bit more uniform.
The previous part should make bug 1589591 obsolete, so it seems useful to make
the code more uniform.
Depends on D152040
Differential Revision: https://phabricator.services.mozilla.com/D152042
A bug is not reported related to "zero copy hardware decoded video" on Windows. Zero video frame copy needs "reuse decoder device ". And it is already enabled on Nightly / Early Beta by Bug 1773714.
RadeonBlockNoVideoCopy is renamed to RadeonBlockZeroVideoCopy
Differential Revision: https://phabricator.services.mozilla.com/D152139
Implement the new dominant axis locking mode for the apz.axis_lock.mode
preference. When using this mode, we do not use the traditional axis locks.
Instead we only consider the input pan displacement for the axis with
a larger value, zeroing out the displacement on the opposite axis.
Differential Revision: https://phabricator.services.mozilla.com/D152104
While I'm here, rename the local variable `styleMargin` to `margin` to make the
naming consistent with the `padding` naming in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D152203
This log goes into `profile.profilingLog[<parent pid>].bufferGlobalController.updates`, an array of data arrays.
See the related `updatesSchema` for what's in those data arrays.
Note: There are no direct tests, as this is intended for advanced human users,
and the format is not guaranteed to stay stable.
Differential Revision: https://phabricator.services.mozilla.com/D151776
If nsNSSSocketInfo::mFd is nullptr, it means the connection has been closed.
This isn't an error, and ClientAuthCertificateSelected shouldn't assert if this
happens.
Differential Revision: https://phabricator.services.mozilla.com/D151962
To be used in about:privatebrowsing Pin Private Window promo message. BLOCK_MESSAGE will be used in a multi action call after user clicks 'Pin To taskbar'. This will help in hiding Pin promo message on current and preloaded tabs
Differential Revision: https://phabricator.services.mozilla.com/D151888
In some non-standard configurations we unexpectedly end up in this paths
without a GBM device - one example being the GPU process. Fail cleanly
instead of crashing in those cases, triggering fallback paths.
Context: in the past DMABuf usage was tightly coupled to GBM. Since the
introduction of the surfaceless and device EGL platforms that is not
longer the case, thus we can't make checks like `IsDMABufWebGLEnabled()`
depend on the presence of a GBM device.
Optimally all affected cases get fixed eventually. Until then and also
for future cases it makes sense to fail softly.
Differential Revision: https://phabricator.services.mozilla.com/D152173