This should marginally improve content-process startup for processes that don't immediately
need to use the system font. No actual change in behavior, just taking the initialization
of the system-font faces out of the startup path.
Differential Revision: https://phabricator.services.mozilla.com/D165386
It will ensure that the BrowserTestUtils.waitForContentEvent has finished
setting up the event listener in content before sending native pan events.
Differential Revision: https://phabricator.services.mozilla.com/D165344
+ Add gfx.color_management.rec709_gamma_as_srgb:true. :'(
In particular, rec709(16/255) -> srgb(31/255). Even though it's
technically correct, it's practically-speaking incorrect, since that's
not what Chrome does, nor what the web expected for years and years.
In practice, basically everyone expects gamma to just be completely
ignored.
What people expect:
* Pretend gamut is srgb(==rec709), but stretch this naively for the
display. If you have a display-p3-gamut display, srgb:0.5 expects to
be displayed as display:0.5, which will be display-p3:0.5 to the eyes.
* Pretend all content gammas (TFs) are srgb(!=rec790), and then bitcast this
naively for the display. E.g. rec709(16/255) should
display the same as srgb(16/255), not srgb(31/255). (Note: display-p3
uses srgb gamma) But if your display has e.g. gamma=3.0, don't
convert or compensate.
This is a formalization of what you get when you spend decades ignoring
color management, and people build things based on behavior-in-practice,
not behavior-in-theory.
Also:
+ gfx.color_management.native_srgb:true for Windows, so we don't use the
display color profile, which no one else does.
+ Add rec2020_gamma_as_rec709, so we have a path towards maybe having
rec2020 use its correct transfer function, rather than srgb (like
rec709).
Differential Revision: https://phabricator.services.mozilla.com/D161857
We already had logic for reclamping the visual viewport offset if the
composition bounds changes, but since the composition bounds is in
ParentLayer (post-zoom) coordinates, this didn't handle the case where
the zoom changes.
Differential Revision: https://phabricator.services.mozilla.com/D164998
All implementors currently simply resolve the promise right away, using
crutch code. Asynchronous usage will be added in the changeset that follows.
Differential Revision: https://phabricator.services.mozilla.com/D163508
Note, changes to the delayed-result codepath are not required because
touched prevented by touch-action always get an eager HandledByContent
result.
Differential Revision: https://phabricator.services.mozilla.com/D164586
The function would combine "has room to scroll (or zoom)" and
"touch action allows scroll (or zoom)", but in future patches
APZ will behave differently in the two cases.
Differential Revision: https://phabricator.services.mozilla.com/D164581
This effectively backs out the fix for bug 1746336, while keeping the test
added in that bug (PanZoomControllerTest#touchActionWithWheelListener)
passing using a different fix approach (remembering the eager status
and using it in the computation of the delayed result).
Differential Revision: https://phabricator.services.mozilla.com/D164114
This brings in various bugfixes and improvements from upstream,
including the fix for bug 1791809 and a workaround for bug 1804530.
In this update, `wgpu_core` leaves the selection of backends to its
users, rather than trying to guess which backends to use itself, based
on the target architecture and operating system. For Firefox, this
means that `gfx/wgpu_bindings/Cargo.toml` is now responsible for
selecting back ends.
Firefox's WebGPU implementation should never use `wgpu`'s GLES
backend. Firefox can now explain this to `wgpu-core`, causing it to
drop its dependency on `glow`, `bitflags_serde_shim` and `slotmap`.
These are no longer vendored, and their exemptions in
`supply-chain/config.toml` can be dropped.
The new `wgpu-core` updates to version 0.37.1+1.3.235 of the `ash`
crate, and this patch moves ash's supply-chain exemption forward to
the new version. We expect to finish vetting that next week, but
because this `wgpu-core` update is urgently needed, we want to extend
the exemption for the time being.
The dependency on `slotmap` had been patched to an empty file in
`build/rust/dummy-web`, which can now be removed.
The new `wgpu-core` no longer uses `cfg_aliases`, so Firefox no longer
needs to vendor that.
Differential Revision: https://phabricator.services.mozilla.com/D164928
My guess is that it was done using shadows to not interfere with the
native look, but actually this just works even with native-looking menus
(like the <select> menulist), because the background-color for those is
set on the menupopup, rather than the ::part(content).
So those have effectively 1px of extra padding (due to the transparent
border), but that seems barely perceptible, and worth the consistency
and simplification.
Differential Revision: https://phabricator.services.mozilla.com/D164716
My guess is that it was done using shadows to not interfere with the
native look, but actually this just works even with native-looking menus
(like the <select> menulist), because the background-color for those is
set on the menupopup, rather than the ::part(content).
So those have effectively 1px of extra padding (due to the transparent
border), but that seems barely perceptible, and worth the consistency
and simplification.
Differential Revision: https://phabricator.services.mozilla.com/D164716
This helps out when clipping to rects with canvas2d. It reduces GPU
usage on the React-Stockcharts benchmark from ~70% down to ~45% on
a desktop gen9 Intel GPU.
It would be better to handle this in the D2D backend like we do in other
backends, but there's not an easy way to detect rectangle paths there.
This was the easiest place to slot it in and shouldn't have too high a
cost for the other places we use the recording backend.
Differential Revision: https://phabricator.services.mozilla.com/D164764
Bug 1798242 did not cause a regression. Then it seems OK to try to enable video overlay without ZeroCopyNV12Texture with non-intel GPUs to release.
Differential Revision: https://phabricator.services.mozilla.com/D164634
As of the prior patch, these are no longer needed. I removed
these with a script, then ran clang-format on the files, then
manually reverted a few unrelated changed from the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D164829
Previously we were querying the current ARRAY_BUFFER_BINDING, which
would fail if you did:
```
BindBuffer(ARRAY_BUFFER, a)
VertexAttribPointer(...)
BindBuffer(ARRAY_BUFFER, b)
```
We would assume we should call VeretxAttribPointer again with `b` bound,
when we need to bind `a` instead.
Unfortunately, this is hard to test, and we only hit this on drivers
where we don't use VAOs, which are rare now.
Differential Revision: https://phabricator.services.mozilla.com/D164744
When we did the major cairo update in bug 739096, most of our old patch files were superseded
and no longer relevant, but I failed to clean them up at the time. So here, we remove all the
old patch files, and create new ones just for the fixes we've applied on top of the new code
from upstream.
I've omitted patch files for fixes that I am aware have already landed upstream, as those will
automatically be included in any future update we take. (It's possible more of the new patch
files will also be obsolete by the time we try pulling a new version, but at least they should
provide a starting point.)
Differential Revision: https://phabricator.services.mozilla.com/D164680
This updates the docker image used for CI on the github.com webrender
repository, so that updates to the WebRender code can continue to be
propagated to github.
Differential Revision: https://phabricator.services.mozilla.com/D164458