It's only meaningfully read in two places:
* WebRender fallback code.
* Some widget DEBUG-only code, which on Linux is ifdef'd and on Windows does
some rather sketchy things like sleeping for 30ms
So I think it should be ok to remove, since WR fallback has its own flashing
pref as well, IIUC.
Differential Revision: https://phabricator.services.mozilla.com/D132313
***
***
Bug 1723233 - Changed nsTArray to CopyableTArray
***
Bug 1723233: moved mLastMessage check inside the lock since we call SendSubtreeTransformsToChromeMainThread from different threads
***
lint fix
Differential Revision: https://phabricator.services.mozilla.com/D131971
When certain IPDL actors owned by the CompositorSession are destroyed,
such as CompositorBridgeChild or UiCompositorControllerChild, we call
GPUProcessManager::NotifyRemoteActorDestroyed() to notify the GPU
process manager that the connection to the GPU process has been lost,
causing it to restart or disable the GPU process.
To avoid doing this when the compositor session has been deliberately
destroyed (which occurs whenever a tab is closed on android, as each
tab has its own widget) we give each actor a "process token". This
token gets cleared when the actor is deliberately destroyed, and we
only notify the GPU process manager in ActorDestroy if the process
token is still set.
During an old refactoring of UiCompositorControllerChild, the
deliberate clearing of the process token was removed. This hasn't been
an issue up until now, as UiCompositorControllerChild is only created
on Android and there has been no GPU process on Android. However, with
the GPU process being implemented in this patch series, we now run in
to this issue: whenever a tab is closed we accidentally bring down the
GPU process.
This patch makes it so that we clear the process token once again in
UiCompositorControllerChild::Destroy, preventing us from accidentally
tearing down the GPU process.
Differential Revision: https://phabricator.services.mozilla.com/D131234
Declare a GPU process and corresponding Service in the
AndroidManifest. This is of a new class GeckoServiceGpuProcess which
inherits from GeckoServiceChildProcess, and provides a binder
interface ICompositorSurfaceManager which allows the parent process to
set the compositor Surface for a given widget ID, and the compositor
in the GPU process to look up the Surface for a widget ID. The
ICompositorSurfaceManager interface is exposed to the parent process
through a new method getCompositorSurfaceManager() in the
IChildProcess interface.
Add a new connection type for GPU processes to GeckoProcessManager,
along with a function to look up the GPU process connection and fetch
the ICompositorSurfaceManager binder. When the GPU process is launched
we store the returned binder in the GPUProcessHost, and when each
widget's compositor is created we store a reference to the binder in
the UiCompositorControllerChild.
Each nsWindow is given a unique ID, and whenever the Surface changes
due to an Android resume event, it sends the new surface for that ID
to the GPU process (if enabled) by calling
ICompositorSurfaceManager.onSurfaceChanged().
Stop inheriting AndroidCompositorWidget from InProcessCompositorWidget
and instead inherit from CompositorWidget directly. This class holds a
reference to the Surface that will be rendered in to. The
CompositorBridgeParent notifies the CompositorWidget whenever it has
been resumed, allowing it to fetch the new Surface. For the
cross-process CompositorWidgetParent implementation it fetches that
Surface from the CompositorSurfaceManagerService, whereas the
InProcessAndroidCompositorWidget can read it directly from the real
widget.
AndroidCompositorWidget::GetClientSize() can now calculate its size
from the Surface, rather than racily reading the value from the
nsWindow. This means RenderCompositorEGL and RenderCompositorOGLSWGL
can now use GetClientSize() again rather than querying their own size
from the Surface.
With this patch, setting layers.gpu-process.enabled to true will cause
us to launch a GPU process and render from it. We do not yet
gracefully recover from a GPU process crash, nor can we render
anything using SurfaceTextures (eg video or webgl). Those will come in
future patches.
Differential Revision: https://phabricator.services.mozilla.com/D131231
So, it turns out I didn't fully test the patch from bug 1740262 after I made my
final changes to it. A change that I had in the patch which I thought was
unnecessary, because it didn't fix the problem by itself, turns out to in fact
be necessary. It turns out we still need to inherit the parent stacking
context's `mRasterizeLocally` value inside gecko, or else we could have scale
changes which get dropped on the WebRender side. I do think long term WebRender
should handle all of this itself, because I believe there are still potential
issues lurking here when we start to think of this across the process boundary,
but I don't think I'm the right person right now to untangle everything to
cleanly move everything necessary into WebRender, so I think the solution for
right now is to have Gecko somewhat but not entirely reduntantly handle raster
space inheritance itself, in addition to WebRender handling raster space
inheritance in order to partially cover the process boundary case. This is not
a pretty solution, but as far as I can tell it fixes the issues that bug
1730710 introduced without regressing the performance back to pre-1730710
levels.
Differential Revision: https://phabricator.services.mozilla.com/D132308
On Android, there is no lower bound on the length of the scroll thumb,
and the dimensions of the subframe in this test were such that the
thumb was barely a speck on the screen, making the test not very useful.
Differential Revision: https://phabricator.services.mozilla.com/D131990
This assertion is known to affect some scenarios involving inactive
scroll frames (see comment 10-11 in this bug). In Fission mode, this
is resolved by making all scroll frames active. In non-Fission mode,
we don't plan to pursue a specific fix so downgrade the assertion
to avoid annoyance for users running debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D131886
As in helper_visual_scrollbars_pagescroll.html, this test performs a
native click on a scrollbar track and needs to wait for the resulting
scroll animation to be kicked off. This fix ensures it waits long
enough.
Differential Revision: https://phabricator.services.mozilla.com/D131885
The test synthesizes a native mouse click on the scrollbar track and then
wants to wait for the scroll animation that triggers to complete, but its
method for waiting was racy and sometimes didn't wait long enough.
Differential Revision: https://phabricator.services.mozilla.com/D131880
This code has been a no-op (in the sense that no one was looking
at the event regions) for Internal/Mock tests since bug 1731700,
and for other tests since bug 1682180.
Depends on D131687
Differential Revision: https://phabricator.services.mozilla.com/D131688
The test also has not been testing anything useful since bug 1682180
(it should have been a "LayersOnly"), but it's also not a good fit
for MockHitTester since it wants to test the hit test itself.
In mochitest form, it can exercise the scenario from bug 1257288
with the production WebRender hit testing codepath.
Depends on D131684
Differential Revision: https://phabricator.services.mozilla.com/D131685
The fact that they are using EventRegions suggests that they only
passed by accident with the default hit-tester (which is WRHitTester
taking an early exit to target the root, since WebRender isn't
actually running), rather than testing the scenario they are intended
to test.
This is actually a latent bug that was introduced in bug 1682180,
when these tests were incorrectly excluded from the "LayersOnly"
subclasses because they happened to pass with the WebRender
early-exit codepath.
Depends on D131683
Differential Revision: https://phabricator.services.mozilla.com/D131684
SingleTouchData has two constructors, one which populates mScreenPoint,
and one which populates mLocalScreenPoint.
The latter is only appropriate for cases where the event is delivered
directly to an APZC, which expects "local" (ParentLayer) coordinates.
For cases where the event is delivered to the tree manager (as in
these tests), mScreenPoint must be populated because this is what
the hit tester looks at.
Differential Revision: https://phabricator.services.mozilla.com/D131683
In bug 1633322 the AddInputBlockCallback API was added to
APZCTreeManager. This is only used by android, and since there is no
GPU process on Android it was not implemented for
APZCTreeManagerChild. This patch adds a remote APZCTreeManager
implementation in preparation for adding a GPU process for Android.
APZCTreeManagerChild::AddInputBlockCallback() works by maintaining a
local map of the added callbacks. It sends a message to the parent via
SendAddInputBlockCallback(), and in RecvAddInputBlockCallback() the
parent calls AddInputBlockCallback() on its local APZCTreeManager
instance. This callback is simply responsible for sending a message
back to the child with SendCallInputBlockCallback(). Upon receiving
this message the child will, finally, look up the original callback
from its local map and call it.
Some care must be taken with the intermediate callback described
above, as because APZCTreeManagerParent is not a refcounted type we
cannot safely capture a reference to it. Instead, we capture the
APZCTreeManagerParent's LayersId, and then look up the instance from
the CompositorBridgeParent using the ID.
Differential Revision: https://phabricator.services.mozilla.com/D131122
On Android the APZ controller thread is the android UI thread, rather
than the Gecko main thread as on other platforms. There some places
where the main thread requires to call IAPZCTreeManager functions that
must run on the controller thread. Currently we use the function
DispatchToControllerThread() prior to calling various IAPZCTreeManager
APIs to achieve this.
This works just fine for now, as there is no GPU process on
Android. However, once we do add a GPU process we will encounter
issues:
Firstly, there will now be a cross-process APZInputBridge rather than
using an in-process APZCTreeManager. The PAPZInputBridge protocol is
managed by PGPU, and therefore must run on the main thread in the
parent process. The input we require to send over the bridge, however,
originates from the UI thread.
To solve this we can convert PAPZInputBridge to a top-level protocol,
and bind it to the UI thread on Android. We can then send input
directly from the UI thread without issues.
Secondly, the PAPZCTreeManager protocol must also run from the main
thread in the parent process, as it is managed by
PCompositorBridge. Unlike PAPZInputBridge we cannot convert
PAPZCTreeManager in to a top level protocol, as it relies on the
ordering guarantees with PCompositorBridge.
We must therefore ensure that we only dispatch IAPZCTreeManager calls
to the controller thread when using an in-process
APZCTreeManager. Out-of-process calls, on the other hand, must be
dispatched to the main thread where we can send IPDL commands from. To
do this, we move the dispatch logic away from the callsites of
IAPZCTreeManager APIs, and in to the APZCTreeManager and
APZCTreeManagerChild implementations themselves.
Differential Revision: https://phabricator.services.mozilla.com/D131120
The computation included the resolution of enclosing scroll frames
in the scrollbar transform. This was correct with Layers (where
the resolution was "pushed down" to descendant layers such that
their layer space represented rendered pixels) but incorrect with
WebRender (where items with transform properties like a subframe
scrollbar are still subject to enclosing transform properties like
the zoom).
This makes the reftests added in the previous patch pass.
Differential Revision: https://phabricator.services.mozilla.com/D130538
For these tests, the reference file also has the resolution (otherwise
the subframe scrollbar thicknesses wouldn't match), the only difference
is async scroll vs. sync scroll.
These tests fail without the fix for this bug.
Differential Revision: https://phabricator.services.mozilla.com/D130537
CLOSED TREE
Backed out changeset 3accfa522abb (bug 1739454)
Backed out changeset 18fdb7a13e63 (bug 1739454)
Backed out changeset 1de7d723923a (bug 1739454)
We accidently duplicate the file descriptor when serializing because we
hit a constructor for ipc::FileDescriptor which duplicates the handle
instead of just taking it. This means we are supposed to close it
explicitly but we've already forgotten about it. We should just do a
move instead to avoid this.
Differential Revision: https://phabricator.services.mozilla.com/D131569
Emilio Cobos Álvarez
sotaro
mleclair
Jamie Nicol
Doug Thayer
Andrew Osmond
Botond Ballo
Iulian Moraru
Brad Werth
Nika Layzell
Florian Quèze
Hiroyuki Ikezoe
Lee Salzman
Alexandru Michis