It would have been nicer and more logical to use a MacIOSurfaceImage to store the colorspace information, however the data passed around is a IOSurface Id via a SurfaceDescriptorMacIOSurface; the original data structure isn't kept; so we must transit the data at the same time as the IOSurface Id.
Also remove unnecessary test (new operator is infallible).
Differential Revision: https://phabricator.services.mozilla.com/D26058
--HG--
extra : moz-landing-system : lando
YUVColorSpace is inseparable from the bit depth as the matrix coefficients to be calculated need the bit depth information.
So let's put the two types together. gfx namespace also makes more sense as that's where we find IntRect, IntSize and other.
The extent of the changes highlight how much similar data structures are duplicated across the code, to the point it's scary.
Differential Revision: https://phabricator.services.mozilla.com/D25347
--HG--
extra : moz-landing-system : lando
This is used by the basic compositor.
Re-using existing logic, however as with other conversion it only handles limited 8 bits ranges (16-235) and to make things worse is rounded aggressively as the focus is on speed.
Differential Revision: https://phabricator.services.mozilla.com/D25345
--HG--
extra : moz-landing-system : lando
All compositors support 10/12 bits images now.
Additionally, add BT2020 support to AOM decoder.
Differential Revision: https://phabricator.services.mozilla.com/D25344
--HG--
extra : moz-landing-system : lando
The existing truncation code did not correctly handle the case of negative zero.
The fix is to avoid using FCMP floating-point comparisons, and check
the sign bit explicitly in a GPR.
Differential Revision: https://phabricator.services.mozilla.com/D26381
--HG--
extra : moz-landing-system : lando
While we don't have an actual need for those builds at the moment, there
is work in progress to get fuzzing builds for aarch64, and as the
previous change showed, the build were busted by other changes since
they were put in place. So we might as well enable them, so as to be
aware of bustage when it happens rather than while working on getting
the fuzzing builds up.
Depends on D27035
Differential Revision: https://phabricator.services.mozilla.com/D27036
--HG--
extra : moz-landing-system : lando
I must have written the rust 1.33 patch before I landed the
linux64-aarch64 patches, so when that landed, it lacked the aarch64
target. (it's still there on the rust 1.32 toolchain)
Differential Revision: https://phabricator.services.mozilla.com/D27035
--HG--
extra : moz-landing-system : lando
This avoids an AssertionError when loading a stylesheet in a nested
event loop. See comment 15 in the bug.
Differential Revision: https://phabricator.services.mozilla.com/D26971
--HG--
extra : moz-landing-system : lando
Nightly-only for now because the proposal only just reached stage 3.
Promise.allSettled is similar to Promise.all, except that each element also has
an own reject handler. Apart from that most code from Promise.all can be reused
for Promise.allSettled, including calling the `CommonPerformPromiseAllRace`
helper function.
Because each element has an own reject handler and we need to track if either
function of the resolve/reject handler pair was already called, it's not
possible to reuse the same trick as in `PromiseAllResolveElementFunction` where
the data-holder slot is used to track if the handler was already called. Instead
`PromiseAllSettledElementFunction` uses the values array to check if the
current index position is still set to `undefined` as a mean to verify that the
resolving functions for each element weren't already called.
Differential Revision: https://phabricator.services.mozilla.com/D25209
--HG--
extra : moz-landing-system : lando
And a shared helper function for Promise.all, Promise.race, and soon
Promise.allSettled to avoid code repetition.
Differential Revision: https://phabricator.services.mozilla.com/D25208
--HG--
extra : moz-landing-system : lando
nsBrowserStatusFilter is updated to not filter out STATE_IS_REDIRECTED_DOCUMENT.
The test here is adding a way to have a "login form" do a post to a server script, which then does a 303 redirect. This mimics what some services, including LinkedIn do during this stage.
Differential Revision: https://phabricator.services.mozilla.com/D26969
--HG--
extra : moz-landing-system : lando
This is a follow-up for Part 1. I find all the candidates by running the
following command under layout/, and manually replace them.
ag -A 1 reflow$ | ag -B 1 state
Differential Revision: https://phabricator.services.mozilla.com/D27162
--HG--
extra : moz-landing-system : lando
nsHTMLReflowState was renamed to ReflowInput in bug 1277129, so remove
the "Html" in the variable name.
Also, remove the comment "ReflowBlock will initialize it." because
ReflowInput::Init() is called in the constructor. We are not using
ReflowInput::CALLER_WILL_INIT flag here.
Differential Revision: https://phabricator.services.mozilla.com/D27024
--HG--
extra : moz-landing-system : lando
Jean-Yves Avenard
Cosmin Sabou
Oana Pop Rus
Brendan Dahl
Chris Manchester
Sean Stangl
Mike Hommey
Emilio Cobos Álvarez
Mathieu Leplatre
Gijs Kruitbosch
nidhi
Nihanth Subramanya
Adam Holm
Lee Salzman
Dale Harvey
Ed Lee
André Bargull
Shane Caraveo
Ting-Yu Lin
Jason Laster
Drew Willcoxon