It allows for more readable code, not having to store multiple times different storage type across multiple objects.
Now each class does one task and only deal with a single texture data type.
Differential Revision: https://phabricator.services.mozilla.com/D26473
--HG--
extra : moz-landing-system : lando
Those classes use raw pointers or references to construction objets. They can only be used while the objects they reference still exist.
While RAII doesn't fully cover this use case, it's close enough. Mark them as such to prevent shooting ourselves in the future.
Differential Revision: https://phabricator.services.mozilla.com/D26471
--HG--
extra : moz-landing-system : lando
It allows for use of default constructor/destructor and leaves no room to incorrectly modify the union members with a wrong type.
Differential Revision: https://phabricator.services.mozilla.com/D26061
--HG--
extra : moz-landing-system : lando
* Remove redundant virtual keywords
* Mark all destructors of inheriting classes as virtual for clarity
* Mark all classes without virtual destructor as final (exposed errors)
* Make destructor virtual where it needed to be (some were missing)
* Replace empty ({}) code declaration in header with = default
* Remove virtual unused methods
I probably missed some, it quickly became a rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D26060
--HG--
extra : moz-landing-system : lando
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
https://drafts.csswg.org/css-scroll-snap-1/#scroll-snap-align
The main logic here is basically same as the old scroll snap implementation,
just iterating over all descendant elements in the scroll container and collect
snap positions. The differences are;
1) the snap positions are specified based on descendant elements instead of
points
2) the snap positions are able to be specified by `block` or `inline` keywords
so that we also need to care the element flow.
more test cases for this are coming in the next commit
3) the target rect is calculated by nsLayoutUtils::TransformFrameRectToAncestor
which means transform is already taken account into it (we have a bug for
the old scroll snap, it's bug 1218745)
some of web platform tests will be added in a subsequent commit
Some of test cases in overflowing-snap-areas.html that accidentally have
passed start failing with this change, all of them will be passed with
subsequent changes in these commit series.
Depends on D21627
Differential Revision: https://phabricator.services.mozilla.com/D21628
--HG--
extra : moz-landing-system : lando
Linux machines using Intel graphics with Mesa drivers being at least
18.2.8.0 and not 4k displays should be able to run WebRender well, given
this is a common configuration used for testing already by Mozilla. This
patch allows users meeting said requirements to join the WebRender
experiments on nightly. WebRender will remain disabled by default for
other configurations/devices.
Differential Revision: https://phabricator.services.mozilla.com/D26796
Linux machines using Intel graphics with Mesa drivers being at least
18.2.8.0 and not 4k displays should be able to run WebRender well, given
this is a common configuration used for testing already by Mozilla. This
patch allows users meeting said requirements to join the WebRender
experiments on nightly. WebRender will remain disabled by default for
other configurations/devices.
Differential Revision: https://phabricator.services.mozilla.com/D26796
We seem to get a spurious mousemove event generated after the mousedown
from somewhere in Gecko. This causes us to trigger the testDriver
continuation an extra time right at the start of the drag, which causes
the test to end before it's supposed to. This patch makes it so we drop
the spurious mousemove.
Differential Revision: https://phabricator.services.mozilla.com/D26829
--HG--
extra : moz-landing-system : lando
ClientTiledPaintedLayer::GetTransformToAncestorsParentLayer calculates
the transform from the layer to its display port ancestor's
parent. This transform is then applied to the calculated display
port.
However, if the display port ancestor participates in a preserve-3d
context then the scroll offset will not be included in the that
layer's transform, it will instead be on the root layer of the
preserve-3d context. This was causing the critical display port to
remain still as the contents of a perspective transform were scrolled,
resulting in content being permanently painted in low-precision as the
page was scrolled down.
Instead, if the display port ancestor participates in a 3d context, we
must find the root of that 3d context then calculate the transform to
*that* layer's parent.
Differential Revision: https://phabricator.services.mozilla.com/D26821
--HG--
extra : moz-landing-system : lando
The way that world content transform is calculated has some
inconsistencies related to transform flattening, compared to
the get_relative_transform implementation.
Reducing usage of this field will make it simpler to take
advantage of the external scroll offset, which is needed for
some of the planned picture caching improvements.
This patch removes the simple uses of world_content_transform,
but there are still a small number of more complicated uses that
need to be handled separately.
Differential Revision: https://phabricator.services.mozilla.com/D26651
--HG--
extra : moz-landing-system : lando