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.
Simon Giesecke
Markus Stange
Ehsan Akhgari
Sylvestre Ledru
Martin Stransky
Michael Smith
David Anderson
Ryan Hunt
Kartikaya Gupta
Mozilla Graphics Team
Jim Chen
Ryan Hunt
Sebastian Hengst
Sotaro Ikeda
Carsten "Tomcat" Book
Phil Ringnalda