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
Nowadays we often use it for Wayland, which is confusing. Also, it
has a bunch of GTK specific functions, which an alternative X11
implementation would like not have. So a explicit name is probably
deserved.
Depends on D114424
Differential Revision: https://phabricator.services.mozilla.com/D114425
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
ClearBeforePaint put the responsibility of clearing the current frame's DrawTarget
onto the widget. This doesn't compose well with WR RenderCompositor that may do
their own internal clearing. Instead, replace this with a GetTransparentRegion API
that can be used by RenderCompositors to limit where they clear so that they are
now fully responsible for clearing.
Differential Revision: https://phabricator.services.mozilla.com/D103253
ClearBeforePaint put the responsibility of clearing the current frame's DrawTarget
onto the widget. This doesn't compose well with WR RenderCompositor that may do
their own internal clearing. Instead, replace this with a GetTransparentRegion API
that can be used by RenderCompositors to limit where they clear so that they are
now fully responsible for clearing.
Differential Revision: https://phabricator.services.mozilla.com/D103253
ClearBeforePaint put the responsibility of clearing the current frame's DrawTarget
onto the widget. This doesn't compose well with WR RenderCompositor that may do
their own internal clearing. Instead, replace this with a GetTransparentRegion API
that can be used by RenderCompositors to limit where they clear so that they are
now fully responsible for clearing.
Differential Revision: https://phabricator.services.mozilla.com/D103253
This code was assuming that the only non-opaque parts of compositor rendering would be the
parts of the window that had vibrancy. But now that the default window background is transparent,
we can have non-vibrant parts where we render into transparency. Dialog windows such as sheet
windows are an example of this.
So instead of using the non-vibrant region of the window as its opaque region, we now use
the region that is covered by opaque Gecko layers. This region is a lot more conservative:
For example, the main browser chrome is now entirely transparent, because the chrome's opaque
parts share a layer with its transparent parts.
As a result, this change slightly affects the CALayer partitioning in the main browser window:
The entire browser chrome is now transparent, not just the tab bar.
The web content area is still opaque.
I think this will be fine. The thing I'm most concerned about is that scrolling inside web
content might cause invalidations of pixels from the chrome, because then we'd recomposite
the CALayers that cover the vibrant tab bar. This doesn't seem to happen most of the time
though, from what I can tell.
Differential Revision: https://phabricator.services.mozilla.com/D51466
The only use of this was inside Android's nsWindow::PreRender.
That method was removed in changeset 81de9d1439b0e352729142f6aa2914674073da03 (bug 1335895).
Differential Revision: https://phabricator.services.mozilla.com/D53771
--HG--
extra : moz-landing-system : lando
This code was assuming that the only non-opaque parts of compositor rendering would be the
parts of the window that had vibrancy. But now that the default window background is transparent,
we can have non-vibrant parts where we render into transparency. Dialog windows such as sheet
windows are an example of this.
So instead of using the non-vibrant region of the window as its opaque region, we now use
the region that is covered by opaque Gecko layers. This region is a lot more conservative:
For example, the main browser chrome is now entirely transparent, because the chrome's opaque
parts share a layer with its transparent parts.
As a result, this change slightly affects the CALayer partitioning in the main browser window:
The entire browser chrome is now transparent, not just the tab bar.
The web content area is still opaque.
I think this will be fine. The thing I'm most concerned about is that scrolling inside web
content might cause invalidations of pixels from the chrome, because then we'd recomposite
the CALayers that cover the vibrant tab bar. This doesn't seem to happen most of the time
though, from what I can tell.
Differential Revision: https://phabricator.services.mozilla.com/D51466
--HG--
extra : moz-landing-system : lando
It looks like a big patch but it's mostly just moved code, with some duplication:
- Layer creation and destruction moves to LayerManagerComposite and RendererOGL.
- BasicCompositor IOSurface setup code moves to BasicCompositor.cpp.
- OpenGL IOSurface setup code moves to CompositorOGL and RenderCompositorOGL.
The duplication is a bit unfortunate but the LayerManagerComposite code will
diverge from the WebRender code soon.
BeginFrame gets a new argument aNativeLayer. This argument will go away again
over the course of this patch queue. But for now, BeginFrame is the best place
to do the layer setup because it's a very close place to PreRender which is
where that code was previously.
I wasn't able to think of a nice way to give CompositorOGL and BasicCompositor
platform-specific behavior without #ifdefs. So now LayerManagerComposite uses
the "cross-platform" NativeLayer interface, but CompositorOGL and
BasicCompositor use NativeLayerCA because they actually need the IOSurface, and
they do that in #ifdef'd code.
Luckily, NativeLayerCA.h can be included in both .cpp files and in .mm files.
Differential Revision: https://phabricator.services.mozilla.com/D42402
--HG--
extra : moz-landing-system : lando
This lets LayerManagerComposite and RendererOGL set the correct opaque region
on the native layer.
Differential Revision: https://phabricator.services.mozilla.com/D42401
--HG--
extra : moz-landing-system : lando
ScreenPixels would be a more appropriate unit. But inside BasicCompositor everything
is in the same coordinate space anyway so we're not getting much benefit from the
units. This patch eliminates a lot of .ToUnknown*() calls.
Differential Revision: https://phabricator.services.mozilla.com/D41680
--HG--
extra : moz-landing-system : lando
On Windows, where the DrawTarget is rewrapped in a Cairo/pixman DrawTarget,
this will now cause Cairo/pixman to be used for the clear.
Differential Revision: https://phabricator.services.mozilla.com/D41673
--HG--
extra : moz-landing-system : lando
To make the HeadlessCompositorWidget work under Windows as well as Linux, I had
to change the way that I hooked it into the existing CompositorWidget system.
Under GTK, the CompositorWidgetInitData and CompositorWidgetDelegate types
provided the information needed by the headless compositor widget already (the
widget client size). On Windows, however, the definitions of these types
differ, and the client size information is simply retrieved from the platform
APIs when needed.
After this patch, CompositorWidgetDelegate is renamed to
PlatformCompositorWidgetDelegate, and a new base class called
CompositorWidgetDelegate is added with "AsPlatformSpecificDelegate()" and
"AsHeadlessCompositorWidget()" methods. In non-headless mode, widgets use
AsPlatformSpecificDelegate() to access the Windows- and GTK-specific delegate
APIs. In headless mode, AsHeadlessCompositorWidget() is used to access the
singular CompositorWidget implementation for headless. Meanwhile, the
CompositorWidgetInitData IPDL type is made into a union which always contains a
headless-specific HeadlessCompositorWidgetInitData struct and under GTK and
Windows also contains an {X11,Win}CompositorWidgetInitData struct.
This also includes a small patch to ensure that the GPU process and
hardware-accelerated compositing are always disabled under headless mode. These
features weren't activated by default in the Linux environments I tested in, but
did end up activating (and then promptly crashing Firefox) when I tested on
Windows.
MozReview-Commit-ID: CocPoHBDV7H
--HG--
extra : rebase_source : 4581fa63aa3a9f32a8dc2672015a35b9be01b20f
This completes the migration of code from the github branch to the graphics
project repo. At this point all webrender-related code should be disabled
unless --enable-webrender is provided in the mozconfig.
MozReview-Commit-ID: Dea8rxM6UPL
This is the first step in using these functions without having a
LayerManagerComposite at all.
MozReview-Commit-ID: 2zkuB7Ox4Ut
--HG--
extra : rebase_source : b23988275f5851a2fd30bd3e8a9931107a224c66
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.
ganguin
criss
Jamie Nicol
Matt Woodrow
Robert Mader
Lee Salzman
smolnar
stransky
Simon Giesecke
Markus Stange
Ehsan Akhgari
Sylvestre Ledru
Michael Smith
David Anderson
Ryan Hunt
Kartikaya Gupta
Mozilla Graphics Team
Jim Chen
Ryan Hunt
Sebastian Hengst
Sotaro Ikeda
Carsten "Tomcat" Book