This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
The in-process compositor assumes that no compositor window was present.
This is not guaranteed to be true if, for example, the preference
`gfx.webrender.flip-sequential` is set.
Make the in-process compositor more closely mirror the out-of-process
compositor. (At present this effectively just means calling ::SetParent
on the compositor window.)
Differential Revision: https://phabricator.services.mozilla.com/D172733
Per Microsoft documentation, DXGI_SCALING_NONE is only supported by
swap chains using DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL; for any other swap
effect, including DXGI_SWAP_EFFECT_SEQUENTIAL, another value must be
supplied. Prior to Windows 10 the only such available entry was
DXGI_SCALING_STRETCH, so use that.
This causes the `CreateSwapChainForHwnd` call to succeed, rather than
causing us to fall back to `CreateSwapChain`. There is no known user-
facing effect here, as DXGI_SCALING_STRETCH is documented to be the
semantics applied by `CreateSwapChain` -- but it does eliminate an error
message from the D3D11 debug layer's output.
Differential Revision: https://phabricator.services.mozilla.com/D171521
At the same time, simplify the inner region support from arbitrary
tile configs to an inner + AA edge section setup. It turns out that
we won't need the extra tiling functionality in follow up patches.
Differential Revision: https://phabricator.services.mozilla.com/D172749
This makes the digits scale up to better fill the box, as it looks a bit odd to have
the box grow with the font size but the digits remain tiny in the middle of it.
One thing that may look a little odd with this version is that 6-digit hexboxes tend
to get smaller digits than 4-digit ones with large font sizes. But I think that's
OK; it allows the 4-digit chars to be more readable, and 6-digit (non-BMP) ones are
generally much rarer.
(And the whole thing is basically cosmetic anyhow; this isn't about rendering web
content as intended, but trying to provide a bit of useful information when the
content is somehow broken or not renderable.)
Differential Revision: https://phabricator.services.mozilla.com/D173463
Add a new string-valued, Rust-visible pref, `dom.webgpu.wgpu-backend`, to `StaticPrefList.yaml` in `modules/libpref/init`. If this string is non-empty, use it to enable the indicated WebGPU backends when we create a `wgpu_core::Global` in `gfx/wgpu_bindings/src/server.rs`. See `StaticPrefList.yaml` for details.
As this is the first time we have exposed a `mirror: always`, `type: DataMutexString` pref to Rust, make the appropriate changes to `generate_static_pref_list.py` to generate the necessary C++ and Rust code to lock the value, make a string copy, and pass ownership back to Rust as an `nsstring::nsACString` (from the `xpcom/rust/nsstring` crate).
Differential Revision: https://phabricator.services.mozilla.com/D173335
Add a new string-valued, Rust-visible pref, `dom.webgpu.wgpu-backend`, to `StaticPrefList.yaml` in `modules/libpref/init`. If this string is non-empty, use it to enable the indicated WebGPU backends when we create a `wgpu_core::Global` in `gfx/wgpu_bindings/src/server.rs`. See `StaticPrefList.yaml` for details.
As this is the first time we have exposed a `mirror: always`, `type: DataMutexString` pref to Rust, make the appropriate changes to `generate_static_pref_list.py` to generate the necessary C++ and Rust code to lock the value, make a string copy, and pass ownership back to Rust as an `nsstring::nsACString` (from the `xpcom/rust/nsstring` crate).
Differential Revision: https://phabricator.services.mozilla.com/D173335
In bug 1823411 prim_shared.glsl's vClipMaskUv was made mediump,
assuming it was safe to do so as it is an unnormalized texture
coordinate. This is, however, causing fuzziness in a test on Adreno
devices, so we are now reverting it to highp.
Differential Revision: https://phabricator.services.mozilla.com/D173468
The in-process compositor assumes that no compositor window was present.
This is not guaranteed to be true if, for example, the preference
`gfx.webrender.flip-sequential` is set.
Make the in-process compositor more closely mirror the out-of-process
compositor. (At present this effectively just means calling ::SetParent
on the compositor window.)
Differential Revision: https://phabricator.services.mozilla.com/D172733
Per Microsoft documentation, DXGI_SCALING_NONE is only supported by
swap chains using DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL; for any other swap
effect, including DXGI_SWAP_EFFECT_SEQUENTIAL, another value must be
supplied. Prior to Windows 10 the only such available entry was
DXGI_SCALING_STRETCH, so use that.
This causes the `CreateSwapChainForHwnd` call to succeed, rather than
causing us to fall back to `CreateSwapChain`. There is no known user-
facing effect here, as DXGI_SCALING_STRETCH is documented to be the
semantics applied by `CreateSwapChain` -- but it does eliminate an error
message from the D3D11 debug layer's output.
Differential Revision: https://phabricator.services.mozilla.com/D171521
When upgrading the NDK to r23, the wrench builds for android fail
because cargo apk starts adding flags to the cargo rustc call it does,
and that's not compatible with the wrench crate having both a lib and a
bin target.
As cargo apk only packages the lib in the apk, we can just be explicit
and build the library only.
Differential Revision: https://phabricator.services.mozilla.com/D173244
When a new scene is swapped in on the render backend thread, its
scroll frames have scroll offsets that come from the main thread
and do not reflect async scroll deltas until such deltas are
sampled from APZ.
It's possible for hit-testing to observe the scene in this
temporary state, potentially leading to incorrect hit-test results.
To avoid this, save the async offsets from the previous scene
and apply them to the new scene until we can sample proper offsets
from APZ.
Differential Revision: https://phabricator.services.mozilla.com/D173100
No functionality change here, just preparing for having different
variations of shaders that make use of ps_quad as a base.
Differential Revision: https://phabricator.services.mozilla.com/D172197
When a new scene is swapped in on the render backend thread, its
scroll frames have scroll offsets that come from the main thread
and do not reflect async scroll deltas until such deltas are
sampled from APZ.
It's possible for hit-testing to observe the scene in this
temporary state, potentially leading to incorrect hit-test results.
To avoid this, save the async offsets from the previous scene
and apply them to the new scene until we can sample proper offsets
from APZ.
Differential Revision: https://phabricator.services.mozilla.com/D173100
The previous patch in this series ensured that every varying is now
given an explicit precision. We want to use mediump where possible for
performance reasons, and highp when required for correctness. Going
forward, in order to ensure that developers have considered what
precision is required for new varyings, this patch adds a shader test
to ensure that they are explicitly qualified.
Shader tests have until now used the `glsl` crate. And as the glsl
crate does not handle preprocessor directive properly, we ran them on
the pre-optimized shader sources. However, the optimization pass
outputs explicit varying precisions even if the input did not contain
them, so that does not work for this case. Instead, we have switched
to use the`glsl-lang` crate, which does handle preprocessor directives
correctly. This does add some duplicate crate dependencies, however
this only affects wrench, not webrender itself.
Differential Revision: https://phabricator.services.mozilla.com/D173029
Mali profiling tools have shown we are frequently fragment bound, in
particular due to varying interpolation. To help mitigate this, we
should use mediump where possible. Currently most of our varyings are
implicitly highp by default. This patch reduces their precision to
mediump where possible. When varyings must remain highp for
correctness reasons, this is now stated explicitly.
As expected, this does cause a fair bit of reftest fuzziness on
Android devices. This patch also updates reftest expectations to
reflect this.
Differential Revision: https://phabricator.services.mozilla.com/D173028
