We had previously encountered a driver bug on Mali Valhall GPUs where
invalidating render targets once they are no longer required results
in rendering artefacts. This invalidation was purely an optimization,
which probably doesn't help much on Mali architecture anyway, so we
can workaround the bug by skipping the invalidation. See bug 1787520
for details.
The latest Mali Valhall GPUs are also affected. This patch therefore
applies the workaround to *all* "Mali-G" models apart from a list of
known working ones. This means we will avoid hitting this issue again
when the next generation of GPUs are released. Once ARM move on to the
next family we can see whether it is still affected and update the
code accordingly if required.
Differential Revision: https://phabricator.services.mozilla.com/D194063
Code like the one from comment 7 seems reasonable. Let's try to disable
prefixed transitions along with prefixed transforms in order to minimize
the compat fallout from CSS zoom.
While I was at it I also fixed the prefixed animation entries in the
property database and crashtests. But those aliases remain enabled.
Differential Revision: https://phabricator.services.mozilla.com/D192129
Instead of starting transitions and animations as a result of a paint,
use the refresh driver tick to do this.
This sets the transition-ready time to the current time during the next
refresh driver tick that it was started on (see mSawTickWhilePending).
This is similar to what's described in the bugs comments, and seems to
work nicely in practice.
We could easily change that (current time) by a paint-based time if
needed (when available), which would be more similar to what we were
doing. But I'd rather do the simple thing for now, and land this shortly
after the soft freeze is over so that we have time to watch out for
regressions.
There's one regression on a test that birtles wrote (using an XHR doc
and switching the timeline to a rendered doc's timeline).
We use the timeline's document rather than the target document to
determine whether to trigger animations now. That's one of the cases
where we'd keep vsync perma-running without this patch, and Chrome also
fails that test. Maybe the test should be removed / the spec should be
tweaked to allow this behavior?
This causes some progression in some CSS transitions tests too, and I
added an extra test for the vsync behavior.
Over-all this is much simpler to reason about and I think we should try
to do this.
Differential Revision: https://phabricator.services.mozilla.com/D193583
Code like the one from comment 7 seems reasonable. Let's try to disable
prefixed transitions along with prefixed transforms in order to minimize
the compat fallout from CSS zoom.
While I was at it I also fixed the prefixed animation entries in the
property database and crashtests. But those aliases remain enabled.
Differential Revision: https://phabricator.services.mozilla.com/D192129
Since the upgrade of the Windows testers to the October 2023 version of Windows,
the anti-aliasing returns different results. The directWrite version changed
from 10.0.22621.1635 to 10.0.22621.2428
Differential Revision: https://phabricator.services.mozilla.com/D193926
Use sigle point of release for EGL surfaces (GLContextEGL::DestroySurface()) and also release Wayland related structures here.
Differential Revision: https://phabricator.services.mozilla.com/D190152
Removed the use of kCTFontOptionsPreferSystemFont that was in the previous version
of this patch, given the issues we saw in bug 1858869 -- that option appears to be
much too aggressive about using system fonts rather than user-installed ones. So
we retain only the gfxPlatformMac font-activation change.
Differential Revision: https://phabricator.services.mozilla.com/D170286
This patch adds a new method for Image subclasses to override in order
to avoid extra copies when the ultimate destination of a readback is
into an IPDL Shmem. It also makes RemoteDecoderManagerParent's
RecvReadback take advantage of it.
Differential Revision: https://phabricator.services.mozilla.com/D192883
It's not used in any of the implementations and this will let us
avoid passing the DrawTarget through to a variety of places.
Differential Revision: https://phabricator.services.mozilla.com/D193462
This is not necessary to fix the observed bug, but as a precaution against excessive
negative tracking, let's clamp the adjusted advance so that it can't become negative
(which seems unlikely to end well).
Also rename the method, given that it is not only used for synthetic bold adjustments
any longer.
(No change in behavior, except in the edge-case of a font that has such small
advances and extreme tracking that it tries to go backwards...)
Depends on D193288
Differential Revision: https://phabricator.services.mozilla.com/D193289
This method (as its name suggests) was originally created to handle synthetic-bold,
which only ever increases the advance, and so its use of an unsigned value for the
adjustment worked ok.
But when applying tracking, the adjustment may be negative, and assigning this to
a uint32_t value takes us into undefined-behavior territory. It seems this worked
"as expected" on x86_64 (using modulo arithmetic), but on arm64 the value just
clamped to zero, and the intended negative tracking doesn't get applied.
Making it an int32_t results in consistent behavior across both architectures.
Differential Revision: https://phabricator.services.mozilla.com/D193288
This is not necessary to fix the observed bug, but as a precaution against excessive
negative tracking, let's clamp the adjusted advance so that it can't become negative
(which seems unlikely to end well).
Also rename the method, given that it is not only used for synthetic bold adjustments
any longer.
(No change in behavior, except in the edge-case of a font that has such small
advances and extreme tracking that it tries to go backwards...)
Depends on D193288
Differential Revision: https://phabricator.services.mozilla.com/D193289
This method (as its name suggests) was originally created to handle synthetic-bold,
which only ever increases the advance, and so its use of an unsigned value for the
adjustment worked ok.
But when applying tracking, the adjustment may be negative, and assigning this to
a uint32_t value takes us into undefined-behavior territory. It seems this worked
"as expected" on x86_64 (using modulo arithmetic), but on arm64 the value just
clamped to zero, and the intended negative tracking doesn't get applied.
Making it an int32_t results in consistent behavior across both architectures.
Differential Revision: https://phabricator.services.mozilla.com/D193288
wgpu dx12 requests to Texture that if its usage has STORAGE_BINDING, D3D12 resource needs to have D3D12_RESOURCE_FLAG_ALLOW_UNORDERED_ACCESS.
The equivalent of D3D12_RESOURCE_FLAG_ALLOW_UNORDERED_ACCESS in D3D11 is D3D11_BIND_UNORDERED_ACCESS. Therefore, D3D11 textures in ExternalTextureD3D11 also require D3D11_BIND_UNORDERED_ACCESS if STORAGE_BINDING is used.
Differential Revision: https://phabricator.services.mozilla.com/D192976
GetAndInitDeviceDisplay() uses DrmRenderDevice to create GL context over drm device so we should set it even if dmabuf operations are disabled.
Differential Revision: https://phabricator.services.mozilla.com/D192933
GetAndInitDeviceDisplay() uses DrmRenderDevice to create GL context over drm device so we should set it even if dmabuf operations are disabled.
Differential Revision: https://phabricator.services.mozilla.com/D192933
