If we want to re-enable SanityTest.jsm test, we need to disable native compositor(DirectComposition) on the testing window, since taking snapshot of native compositor is very slow on Windows. Then CompositorOptions could be used to notice to disable native compositor(DirectComposition).
To notice it from SanityTest.jsm to gecko, nsIAppWindow::needFastSnaphot() is used.
Differential Revision: https://phabricator.services.mozilla.com/D130824
This patch just adds the plumbing to allow for baked in blocklist rules
or the downloadable blocklist to prevent certain configurations from
getting WebGPU. It does not add any rules.
It also changes us from allowing WebGPU only in nightly, including
tests, to not release and not beta. This allows try to run the WebGPU
tests as expected, since even try builds forked from mozilla-central are
not considered nightly builds by CI (or so it seems).
Differential Revision: https://phabricator.services.mozilla.com/D141682
Automatically generated rewrites of all ParamTraits and IPDLParamTraits
implementations in-tree to use IPC::Message{Reader,Writer}.
Differential Revision: https://phabricator.services.mozilla.com/D140004
For WebGPU, we produce the textures in the compositor process and the
content process doesn't need to be that involved except for hooking up
the texture to the display list. Currently this is done via an external
image ID.
Given that WebGPU needs to work with OffscreenCanvas, it would be best
if its display pipeline was consistent whether it was gotten from an
HTMLCanvasElement, OffscreenCanvas on the main thread, or on a worker
thread. As such, using an AsyncImagePipeline would be best.
However there is no real need to bounce the handles across process
boundaries. Hence this patch which adds CompositableInProcessManager.
This static class is responsible for collecting WebRenderImageHost
objects backed by TextureHost objects which do not leave the compositor
process. This will allow WebGPUParent to schedule compositions directly
in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D138588
For WebGPU, we produce the textures in the compositor process and the
content process doesn't need to be that involved except for hooking up
the texture to the display list. Currently this is done via an external
image ID.
Given that WebGPU needs to work with OffscreenCanvas, it would be best
if its display pipeline was consistent whether it was gotten from an
HTMLCanvasElement, OffscreenCanvas on the main thread, or on a worker
thread. As such, using an AsyncImagePipeline would be best.
However there is no real need to bounce the handles across process
boundaries. Hence this patch which adds CompositableInProcessManager.
This static class is responsible for collecting WebRenderImageHost
objects backed by TextureHost objects which do not leave the compositor
process. This will allow WebGPUParent to schedule compositions directly
in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D138588
The reason why the global ScrollGeneration::sCounter doesn't work for the APZ
case is the APZ sampler thread is per our top level browser window, so if
there are multiple browser windows at the same time, the sCounter will be muted
from different sampler threads.
Differential Revision: https://phabricator.services.mozilla.com/D133439
There is one thing to note in this patch that is a change: this patch changes the displayport that we log for test purposes from the critical display port to the display port.
This will only be different on android. If tests were checking this then they were broken because the critical display port has no significance. I did a quick survey of the tests I could find that used this. None of them seem like they really want the critical display port (given the new world where critical display port has no significance).
Depends on D127350
Differential Revision: https://phabricator.services.mozilla.com/D127351
Instead of passing this flag all of the time for double taps we want to decide to do this or not in CalculateRectToZoomTo. Moving it into ZoomTarget seems like a good way to do this (which is done in the next patch).
Differential Revision: https://phabricator.services.mozilla.com/D128435
This provides feedback to the user, otherwise nothing happens and the user doesn't know if their input was accepted or not. This matches what Chrome does.
We add a new flag for ZoomToRect that only double tap uses. We also need to add the cursor position to the ZoomTarget struct as that is what we will be zooming in on. (CalculateRectToZoomTo has a little bit of refactoring to calculate this point sooner and without an intermediate variable.)
The rest of the patch is some logic in ZoomToRect to decide when to do this, and some math to compute the zoom to rect (which is similar to the zoom out code).
Differential Revision: https://phabricator.services.mozilla.com/D116370
Because adding or removing a scrollbar can change without the resolution changing (in particular, when zooming in we can add scrollbars) and we don't want to detect that content has updated it's resolution and override our (apz) resolution in that case.
This happens when double tapping creates a scrollbar and the resulting repaint updates the apz resolution while the zoom animation is ongoing, messing it up for a frame.
Adding a field for frame metrics just for this is kind of gross, but it can go away when that todo is fixed in NotifyLayersUpdated.
Differential Revision: https://phabricator.services.mozilla.com/D113303
Also rename IsAsyncZoomContainer to GetAsyncZoomContainerId, since it returns a maybe this serves both purposes.
We need this for the next patches.
Differential Revision: https://phabricator.services.mozilla.com/D112484
Also rename IsAsyncZoomContainer to GetAsyncZoomContainerId, since it returns a maybe this serves both purposes.
We need this for the next patches.
Differential Revision: https://phabricator.services.mozilla.com/D112484
If we double tap on an element that is narrower than the viewport at maximum we can get into a situation where we zoom on part (say the bottom half) of that element but we could easily fit the entire element.
This happens because the code that calculate the rect to zoom to (CalculateRectToZoomTo) doesn't know about the maximum zoom. So it proceeds as though we will fit the width of the element. Under that assumption we will have to cut off part of the element vertically, so the code centers the rect on the users tap point.
This ends up cutting off part of the element vertically when it is clear that the whole element can fit on screen, which is a pretty ugly result.
This is not my favourite patch. This seemed to make the most sense. Another option I considered was passing the tap point through to AsyncPanZoomController::ZoomToRect but I think this approach came out better: the calculation all happens in one place at one time.
Differential Revision: https://phabricator.services.mozilla.com/D110538
We do want APZEventResult to have a valid mHandledResult in the case of
nsEventStatus_eConsumeDoDefault.
Note that when we call SetStatusAsConsumeDoDefault() with a InputBlockState,
in ReceiveScrollWheelInput() for example, we need to keep the block alive there,
so each block is now RefPtr-ed instead of a raw pointer in such functions (the
raw pointer is sometimes the active one (mActiveWheelBlock etc.) which will be
discarded in ProcessQueue()).
Differential Revision: https://phabricator.services.mozilla.com/D103417
We do want APZEventResult to have a valid mHandledResult in the case of
nsEventStatus_eConsumeDoDefault.
Note that when we call SetStatusAsConsumeDoDefault() with a InputBlockState,
in ReceiveScrollWheelInput() for example, we need to keep the block alive there,
so each block is now RefPtr-ed instead of a raw pointer in such functions (the
raw pointer is sometimes the active one (mActiveWheelBlock etc.) which will be
discarded in ProcessQueue()).
Differential Revision: https://phabricator.services.mozilla.com/D103417
The pref gfx.webrender.software.unaccelerated-widget.allow may be used
to allow software WebRender to be used with new windows/popups that have
transparency on Windows. Otherwise they would fallback to basic layers.
Similarly, the pref gfx.webrender.software.unaccelerated-widget.force
may be used to force software WebRender for all windows that would
fallback to basic layers.
Differential Revision: https://phabricator.services.mozilla.com/D104855
The pref gfx.webrender.software.unaccelerated-widget.allow may be used
to allow software WebRender to be used with new windows/popups that have
transparency on Windows. Otherwise they would fallback to basic layers.
Similarly, the pref gfx.webrender.software.unaccelerated-widget.force
may be used to force software WebRender for all windows that would
fallback to basic layers.
Differential Revision: https://phabricator.services.mozilla.com/D104855
The pref gfx.webrender.software.unaccelerated-widget.allow may be used
to allow software WebRender to be used with new windows/popups that have
transparency on Windows. Otherwise they would fallback to basic layers.
Similarly, the pref gfx.webrender.software.unaccelerated-widget.force
may be used to force software WebRender for all windows that would
fallback to basic layers.
Differential Revision: https://phabricator.services.mozilla.com/D104855
Since bug 1650183, the value returned by this function is not
necessarily the composition size of the RCD-RSF, but may be
a smaller size suitable for bounding the composited size of
scroll frames in a given process.
Differential Revision: https://phabricator.services.mozilla.com/D104463
