While we're here, fix the measurement of ' ' and 'x' so that we don't
measure the .notdef glyph if those glyphs aren't present.
Differential Revision: https://phabricator.services.mozilla.com/D23423
--HG--
extra : moz-landing-system : lando
Add an experimental code path that makes use of the pixel local
storage extension available on many mobile GPUs.
This code path is currently disabled by default, as the support
is not complete for all primitives and blend modes. The initial
aim is to get feature parity with the existing renderer.
Once that's complete, we can take advantage of the (minimum)
12 bytes per pixel of high speed on-tile memory to store custom
data.
Clip masks are a good use case for this, since they map 1:1 with
the position of the fragment they are clipping. Using this for
clip masks allows us to handle clipping on mobile GPUs in a much
more efficient way - we can skip (a) separate render targets,
(b) target resolve (c) sample the mask texture during rendering.
Depends on D24123
Differential Revision: https://phabricator.services.mozilla.com/D24124
--HG--
extra : moz-landing-system : lando
RenderCompositorEGL is also used on wayland, but SharedGL is not enabled on wayalnd. Since SharedGL caused flickering, when multiple windows were opened on wayland.
Differential Revision: https://phabricator.services.mozilla.com/D23786
--HG--
extra : moz-landing-system : lando
`gecko_profiler_add_text_marker` was being passed a character pointer and a
length to construct a `nsDependentCString`. However, these values were coming
from a Rust `&str`, which is not null-terminated, causing an debug assertion to
be hit (and possible memory safety issues if mishandle the string). We now
construct an `nsDependentCSubstring` instead.
Differential Revision: https://phabricator.services.mozilla.com/D24032
--HG--
extra : moz-landing-system : lando
Most rounded rect clips in real content are (a) axis aligned and
(b) have uniform radii.
When these conditions are met, we can run a fast path for clip
mask generation that uses significantly fewer ALU shader ops.
This is not typically a bottleneck on desktop GPUs, but can have
a large performance impact on mobile GPUs (and perhaps low end
integrated GPUs).
The Mali shader analyzer reports the slow path for the rounded
rect clip shader to be 94 cycles per fragment, while the fast
path is 10 cycles.
Differential Revision: https://phabricator.services.mozilla.com/D23817
--HG--
extra : moz-landing-system : lando
The upcoming WebXR API (Bug 1419190) requires intermediate calculations of real-world space coordinates to have more precision with larger ranges. I expect that double precision matrix and quaternions will also be useful in other graphics and layout work.
It would not be ideal to expand the existing classes to always use double precision, as it would incur a significant performance penalty on certain platforms (eg, Arm). The double-precision variants should be used only when required.
The existing gfx::Matrix4x4 and gfx::Quaternion implementation can be extended with templates to generate both single and double precision variants.
Differential Revision: https://phabricator.services.mozilla.com/D22010
--HG--
extra : moz-landing-system : lando
We haven't seen any AMD related bugs on Nightly so I'd like to expand
our scope further.
Differential Revision: https://phabricator.services.mozilla.com/D23944
--HG--
extra : moz-landing-system : lando
In GLES 3 GLSL, the default precision for ints is highp (32 bit) in
vertex shaders, but only mediump (16 bit) in fragment shaders.
To render linear and radial gradients the fragment shader must fetch
the gradient stops from the gpu cache, using an address variable. This
variable is a 16 bit int, so if the stops data is located at
too high an address (row 32 or greater) then this value will have
overflown and we fetch from the wrong location. This was resulting in
garbage being drawn instead of the correct gradients.
To fix this, any address used in a fragment shader must be marked as
highp. This includes the varying input which supplies the address, and
the arguments to any functions used for the fetch.
Differential Revision: https://phabricator.services.mozilla.com/D23669
--HG--
extra : moz-landing-system : lando
We haven't seen any AMD related bugs on Nightly so I'd like to expand
our scope further.
Differential Revision: https://phabricator.services.mozilla.com/D23944
--HG--
extra : moz-landing-system : lando
This eliminates the need to additionally modify gfx.logging.level on
non-debug builds to make apz.printtree output show up.
Differential Revision: https://phabricator.services.mozilla.com/D23880
--HG--
extra : moz-landing-system : lando
And rename the constants to not be prefixed by TOUCH_ACTION_, since that's part
of the type name anyway.
Differential Revision: https://phabricator.services.mozilla.com/D23413
--HG--
extra : moz-landing-system : lando
Most rounded rect clips in real content are (a) axis aligned and
(b) have uniform radii.
When these conditions are met, we can run a fast path for clip
mask generation that uses significantly fewer ALU shader ops.
This is not typically a bottleneck on desktop GPUs, but can have
a large performance impact on mobile GPUs (and perhaps low end
integrated GPUs).
The Mali shader analyzer reports the slow path for the rounded
rect clip shader to be 94 cycles per fragment, while the fast
path is 10 cycles.
Differential Revision: https://phabricator.services.mozilla.com/D23817
--HG--
extra : moz-landing-system : lando
Now, its time to let individual transform run on the compositor thread.
Depends on D19636
Differential Revision: https://phabricator.services.mozilla.com/D22566
--HG--
extra : moz-landing-system : lando
This function was added for B2G actually, to check if the layer has OMTA for
painting high-res layer. However, It's worth to let it also check other
OMTA transform-like properties.
Depends on D22565
Differential Revision: https://phabricator.services.mozilla.com/D19636
--HG--
extra : moz-landing-system : lando
On the sender side of transactions, we have to convert the individual transforms
to the proper types in layers::Animations, and this includes SetAnimatable and
the definition in LayersMessages.
On the compositor side (i.e. received side of transactions). Basically, we
convert the list of layers::Animation into a list of `PropertyAnimationGroup`,
which is an intermediate value. And then use this list to do interpolation for
each property in `SampleAnimationForEachNode`, which will return a list of
`RefPtr<RawServoAnimationValue>`.
Depends on D23062
Differential Revision: https://phabricator.services.mozilla.com/D22565
--HG--
extra : moz-landing-system : lando
The original implementation about "setting animations" is a little bit hard
to read. In `SetAnimations()`, we create a new intermediate data,
`AnimData`, and we mutate the original animations. And then iterate this
mutated animations & intermediate data for sampling. In this bug, we are
planning to group the AnimData as a useful data structure for supporting
multiple properties transform-like animations, so it seems the structure
of original animations may be hard to use after that. Therefore,
we decide to do some reworks on this:
First, we do renames,
1. InfalliableTArray to nsTArray. (They are the same.)
2. AnimData to PropertyAnimation.
3. SetAnimations() to ExtractAnimations(), which returns
nsTArray<PropertyAnimationGroup>. Each entry in the array is for one
property. In this patch, there is only one entry. We will extend this
to multiple entries in the next patch.
And then rework `ExtractAnimations()`, which stores all the necessary data
in `PropertyAnimationGroup`. For WR, we store this in
`CompositorAnimationStorage`. For non-WR, we store it in `AnimationInfo`.
So we can just use this organized data structure for supporting multiple
properties animations. (See the next patch.)
Depends on D22563
Differential Revision: https://phabricator.services.mozilla.com/D23062
--HG--
extra : moz-landing-system : lando
Both layers and web-render use this function, so we factor it out.
Depends on D22562
Differential Revision: https://phabricator.services.mozilla.com/D22563
--HG--
extra : moz-landing-system : lando
It seems this function uses some FFIs to generate the AnimationValue,
We could move it into AnimationValue class, although what we really need is
RefPtr<ServoAnimationValue>.
Maybe we should use AnimationValue everywhere, instead of the Servo type.
This could be done by other patches.
Differential Revision: https://phabricator.services.mozilla.com/D22562
--HG--
extra : moz-landing-system : lando
The only time that the ancestor spatial node index is read is
during push_stacking_context. This means that even if it was
used as an ancestor for a 3d context, we can safely collapse
it in to the parent stacking context during flattening, if it
is otherwise redundant.
This is a partial fix for picture caching heuristics failing
with the display list produced on mobile devices.
Differential Revision: https://phabricator.services.mozilla.com/D23633
--HG--
extra : moz-landing-system : lando
