The detection is inadequate and the workaround does not work on all
versions of Android. Later patches in this series will replace this
with something better.
Differential Revision: https://phabricator.services.mozilla.com/D176719
The detection is inadequate and the workaround does not work on all
versions of Android. Later patches in this series will replace this
with something better.
Differential Revision: https://phabricator.services.mozilla.com/D176719
In bug 1772839 we were seeing a large number of crashes due to
encountering a webrender error after exhausting all fallback
configurations. At least in some cases, this was due to the compositor
being resumed with an Android Surface that was already in an abandoned
state, meaning we can never succeed in creating an EGL Surface.
We added a check for this condition, and a workaround, to the
GeckoView java code. However, we are still seeing crash reports
matching this signature. To help determine whether these are also due
to the Surface being abandoned, or due to some other reason, this
patch adds a deliberate crash much earlier in the pipeline if we
detect an abandoned Surface.
Differential Revision: https://phabricator.services.mozilla.com/D160042
On Android we have until now determined the compositor widget's size
by querying the values from the ANativeWindow. However, since bug
1780093 landed we can now switch between which Surface we are
rendering in to, and as a result we appear to be using the wrong size
some of the time.
This patch is a speculative attempt to fix this, by using the size
passed to ResumeAndResize() (which itself comes from the Surface's
surfaceChanged() callback) rather than querying the window.
Differential Revision: https://phabricator.services.mozilla.com/D154909
One possible cause of the failures to create an EGLSurface we are
seeing in bug 1772839 is that the Surface's underlying BufferQueue has
already been abandoned. In such circumstances,
ANativeWindow_getWidth/Height will return a negative value. If this
occurs, ensure we annotate crash reports via gfxCriticalNote. This
will allow us to determine whether the crashes we are seeing are
indeed due to an abandoned BufferQueue, or some other reason.
Differential Revision: https://phabricator.services.mozilla.com/D151360
On Android we have long since calculated the compositor widget size
from the Surface rather than using the main thread widget size. This
is to avoid a trip via the main thread in response to a
ResumeAndResize event on the UI thread.
AndroidCompositorWidget::mClientSize therefore gets calculated when
the compositor is resumed.
However, it is possible in some circumstances for the compositor to
receive a display list prior to it being resumed. In this bug's case,
SyncResumeAndResize is getting called before the UI thread has been
notified that the compositor has been initialized. It therefore cannot
resume the compositor, and we instead resume the compositor on the
subsequent NotifyCompositorCreated call. This starts a race between
the main thread paint and NotifyCompositorCreated being scheduled on
the UI thread then resuming the compositor via
PUiCompositorController. If we receive
WebRenderBridgeParent::RecvSetDisplayList prior to
UiCompositorControllerParent::RecvResumeAndResize, then
AndroidCompositorWidget::mClientSize will be zero. This results in us
setting zero-sized webrender scene rect, leading to webrender exiting
early during rendering, resulting in a black screen.
To fix this, allow the main thread to set the AndroidCompositorWidget
size, in addition to the UI thread being able to set it. We do so by
adding a NotifyClientSizeChanged method to
PlatformCompositorWidgetDelegate, called from
nsWindow::OnSizeChanged. The cross-process implementation of this uses
an IPDL call on PCompositorWidget, which shares a top-level protocol
with PWebRenderBridge, meaning calls are guaranteed to occur in
order. This means a resize event on the main thread is guaranteed to
set the CompositorWidget size before the display list from the
subsequent paint is received.
Differential Revision: https://phabricator.services.mozilla.com/D144594
In bug 1756700 we added size constraints to the size of the android
nsWindow. This avoided hitting webrender's window_size_sanity_check
assertion during the geckoview giantScreenshot test when initializing
the webrender renderer.
However, the sanity check occurs whenever the webrender document size
is updated, which can occur when a new display list is sent in
addition to renderer initialization. In
WebrenderBridgeParent::SetDisplayList we take the window size from
CompositorWidget::GetClientSize rather than
nsWindow::GetClientSize. On Android, AndroidCompositorWidget
calculates its size directly from the Surface/ANativeWindow to avoid
having to pass through the main thread when a ResumeAndResize message
is sent from the UI thread to the compositor thread. This means the
nsWindow size constraints have no effect on the compositor widget
size.
This patch additionally clamps the max size of
AndroidCompositorWidget, meaning we never send too large a size to
webrender and therefore avoid the assertion.
Differential Revision: https://phabricator.services.mozilla.com/D140492
Since bug 1747116 landed, if the compositor is reinitialized whilst
the Android Surface is invalid, we avoid crashing when querying the
window size and instead keep the compositor in a paused state.
However, in this case we will believe the widget size is 0x0 until the
compositor is eventually resumed. If webrender receives a display list
during this time, it will set an empty view rect. This means when the
compositor is subsequently resumed webrender believes it has nothing
to render, and we get stuck in a state where nothing is ever rendered
to the screen.
This patch initializes the AndroidCompositorWidget with an initial
size, which avoids the problem.
Differential Revision: https://phabricator.services.mozilla.com/D135711
If AndroidCompositorWidget's surface reference points to a surface
that has been destroyed, we can end up with a null ANativeWindow
pointer. This can result in crashes when using it to query the window
size.
This patch makes it so that we use the native window to query the size
only when the surface has changed rather than for every call to
GetClientSize(). This allows us to guard against a null pointer in a
single place. If we have a null pointer then return false from
OnCompositorSurfaceChanged(). CompositorBridgeParent::ResumeComposition()
will handle that by not resuming the compositor, like it already does
if WebRenderBridgeParent::Resume() fails.
Additonally, when we receive a pause event from GeckoView ensure that
we always set the mCompositorPaused flag to true, even if the
UiCompositorController is null. This avoids a possible cause of the
situation described above - if we receive a pause event (eg the app is
minimised) during compositor reinitialization (while the
UiCompositorController is temporarily null) we would not set that flag
to true, and would therefore resume compositing in to an invalid
surface.
Depends on D135117
Differential Revision: https://phabricator.services.mozilla.com/D135118
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
gfxUtils::ConvertBGRAtoRGBA() could be removed. BGRA->RBGA conversion could be done by DrawTargetSkia::CopySurface() in RenderCompositorSWGL::CommitMappedBuffer(). Though DrawTargetCairo::CopySurface() does not do the conversion.
On Android, RenderCompositorSWGL is not expected to be used on release. It is only for testing for now.
Differential Revision: https://phabricator.services.mozilla.com/D118449
It caused us substantial confusion investigating this bug under the belief that
StartRemoteDrawingInRegion may have been modifying the dirty region. None of our
existing widget code anymore uses the API in this way, so it makes sense to just
force this dirty region to be const so that we no longer support the assumption
and alleviate confusion in the future about how our widget code actually behaves.
Depends on D106246
Differential Revision: https://phabricator.services.mozilla.com/D106247
This version of the Dynamic Toolbar moves the animation of the toolbar
from the Android UI thread to the compositor thread. All animation for
showing and hiding the toolbar are done with the compositor and a static
snapshot of the real toolbar.
MozReview-Commit-ID: BCe8zpbkWQt
Add AndroidCompositorWidget to act as the intermediary between gfx code
and GeckoLayerClient, in place of AndroidBridge. AndroidCompositorWidget
currently inherits from InProcessCompositorWidget, but when Android
eventually supports OOP compositing, it will be made to inherit from
CompositorWidget directly.
Jamie Nicol