This replaces the use of a single large ring buffer.
The buffers are still processed in parallel and are recycled to reduce
allocation. Events that do not fit in the default sized buffer have a separate
buffer created to fit them. These large buffers are not recycled.
Separate shared memory is used for readback, with a single shmem cached for this
purpose. Generally only one cached shmem should be required, because the
operations that usually readback the data do it straight away.
Differential Revision: https://phabricator.services.mozilla.com/D193207
In wgpu, command encoders and command buffers actually share the same identity and resource, so dropping one drops the other. This commit makes it so that our gecko wrappers take that into account. The lifetime is now tied to the encoder which may be held alive by a command buffer if there is one.
Differential Revision: https://phabricator.services.mozilla.com/D193313
In wgpu, command encoders and command buffers actually share the same identity and resource, so dropping one drops the other. This commit makes it so that our gecko wrappers take that into account. The lifetime is now tied to the encoder which may be held alive by a command buffer if there is one.
Differential Revision: https://phabricator.services.mozilla.com/D193313
With the change, yuv BufferTexture is uploaded to D3D11 NV12 texture also if webrender supports D3D11 and NV12.
Calling GpuProcessD3D11TextureMap::GetTexture() is changed from RenderDXGITextureHost::EnsureD3D11Texture2DWithGL() to RenderDXGITextureHost::EnsureD3D11Texture2D(), since the EnsureD3D11Texture2DWithGL() is not called with WebRender(Software D3D11).
Differential Revision: https://phabricator.services.mozilla.com/D194171
During local testing, I observed the test failing because we were still
collecting samples after the animations had completed. Since we are
only synthesizing wheel events that trigger animations for a certain
duration (1500 ms), it's safer to only check samples for 1500 ms.
Depends on D194018
Differential Revision: https://phabricator.services.mozilla.com/D194019
It needs to work this way because GenericScrollAnimation can receive
an absolute destination in UpdateDestination(), and the caller will
pass in a destination which does take into account any previous
content shift.
(And the caller needs to work this way because e.g. it may adjust
the destination to nearby snap points, and we want snap points near
the actual final destination, not an intermediate value that will
have a content shift applied on top of it.)
This fixes APZCSmoothScrollTester.ContentShiftThenUpdateDeltaBezier.
Depends on D193717
Differential Revision: https://phabricator.services.mozilla.com/D193978
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
