RenderCompositorOGL currently has many responsibilities including supporting
OpenGL compositor for Linux, whole-window compositing for Mac NativeLayerCA,
and per-cache-tile compositing for Mac NativeLayerCA. With the addition of
support for SWGL, this becomes even further complicated.
It becomes advantageous to separate out RenderCompositorOGL specifically as
only the basic OpenGL compositing case, as that naturally yields a simple and
isolated RenderCompositor.
What is left over becomes RenderCompositorNative, a basis for implementing
NativeLayer-based RenderCompositors. To cleanly isolate state and details of
when HW compositing or SW compositing is being used, these are further split
off into RCNativeOGL and RCNativeSWGL versions that deal with specific
isolated details of OpenGL and SWGL respectively.
RCNativeOGL deals with just setting up OpenGL FBOs for NativeLayers.
RCNativeSWGL's new task is just to deal mapping NativeLayers and providing
SWGL FBOs for them without involving OpenGL.
Differential Revision: https://phabricator.services.mozilla.com/D80270
RenderCompositors for SWGL that wish to provide accelerated compositing need to
subvert the existing Bind/Unbind hooks in the WR compositor. These compositors
need to keep track of their HW tiles without actually binding an OpenGL FBO
for WR to render picture cache tiles. SWGL needs to intervene and get a backing
buffer for tile from the RenderCompositor so that it can create a SWGL FBO for
WR to render the picture cache tile to.
To that end, this adds MapTile/UnmapTile as a replacement for Bind/Unbind for
those scenarios. This is done in a way that it affects only the WrCompositor of
webrender_bindings without actually altering WR's Compositor interface. This is
beneficial because WR does not have to understand the details of SWGL
integration and also so as not to complicate other users of WR such as Servo
who are not currently utilizing SWGL at all.
RenderCompositorOGL is initially modified to use these hooks in this patch. It
later became more convenient to restructure that in a follow-up patch.
Differential Revision: https://phabricator.services.mozilla.com/D80269
This is a first implementation of a software-only SWGL RenderCompositor
that relies on the existing widget hooks for Basic compositing. It attempts
to lock the widget and get a DT whose underlying data it can supply directly
to SWGL to composite to. Critically, it does not rely on OpenGL or any other
form of HW accel to function. The interface between the RenderCompositor and
SWGL will be further refined in follow-up patches.
Differential Revision: https://phabricator.services.mozilla.com/D80268
For performance reasons in SWGL software compositors. to avoid unnecessary
full-screen copies of the framembuffer, we need to allow those compositors to
map their underlying widget surfaces and pass that buffer to SWGL so that they
can be directly rendered to. That also requires supporting custom strides, as
we can't always enforce the particular layout of the buffers handed off to us.
To that end, InitDefaultFramebuffer is generalized to take such information
and then many places where we rely on a specific hard-coded SWGL-calculated
stride have been altered to deal with a caller-supplied stride.
Differential Revision: https://phabricator.services.mozilla.com/D80267
This class isn't used anymore, and it's safe to remove it.
We take this as an opportunity to remove Pool#cleanup and
Pool#isEmpty, which each only had one callsite.
Some comments are updated to not mention ActorPool.
Differential Revision: https://phabricator.services.mozilla.com/D80602
Remove pools and make target actors manage themselves.
devtools/server/tests/browser/browser_navigateEvents.js was modified
since the targetActor can't be retrieved with `searchAllConnectionsForActor`
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D67510
While the comment for 'GetFlatpakPortalEnv' said
"We use the same code as gtk_should_use_portal() to detect
if we're in flatpak env", this was not actually true, since the
code only checked whether the environment variable 'GTK_USE_PORTAL'
was set at all, ignoring its value, while the gtk implementation
checks that it is set and that the first character is '1'
(which was already true in the gtk as of the commit that the
comment refers to, [1]).
Adapt it to check for the actual value here, according to what
is also done at [2], so that setting 'GTK_USE_PORTAL=0' or
'GTK_USE_PORTAL=1' in the environment works as expected.
I ran into this while looking at why bug 1517074 still occured
with the native file chooser presumably having been disabled by
starting Firefox using
GTK_USE_PORTAL=0 firefox
with gtk 3.24.20 that does not yet have the fix for gtk issue [3].
[1] e0ce028c88/gtk/gtkprivate.c (L272)
[2] https://searchfox.org/mozilla-central/rev/37932bfc600f97ec923464086dc12cdaa72aefde/widget/gtk/nsFilePicker.cpp#608
[3] https://gitlab.gnome.org/GNOME/gtk/-/issues/1820
Differential Revision: https://phabricator.services.mozilla.com/D80073
In most methods of `WSRunScanner`, `WSFragment`s are never used. Therefore,
this patch makes them created when they are necessary.
Depends on D80315
Differential Revision: https://phabricator.services.mozilla.com/D80638
This patch would
- introduce new methods `SetEnableFullScreen()` and `SetEnablePictureInPictureMode()` on `MediaControlKeySource`
- notify the change of enabling/disabling the fullscreen and picture-in-picture mode to `MediaControlKeySource`
The advantage of doing this is
- to allow the key source to do corresponding operations when media enters/leaves the fullscreen/picture-in-picture
eg. GeckoView would use them to implement its API, `onFullscreen()` and `onPictureInPicture()`
Differential Revision: https://phabricator.services.mozilla.com/D79785
This patch would
- active the controller when it enters fullscreen or picture-in-picture mode
The advantage of doing this is
- allow to control media even if media doesn't start
Differential Revision: https://phabricator.services.mozilla.com/D79766
This patch would
- notify media controller when media enters/leaves fullscreen
The advantage of doing this is
- prework of being able to control media when media enters fullscreen
Differential Revision: https://phabricator.services.mozilla.com/D79765
This patch would
- stop notifying media key to media in content process is the controller is inactive
The advantage of doing this is
- to prevent unexpectedly controlling an inactive controller
Differential Revision: https://phabricator.services.mozilla.com/D79235
This patch would
- build the relationship between a media element and the media controller when media finishes loading, instead of building that after starting playing media
The advantage of doing this is
- the prework of being able to control media before media starts playing
Differential Revision: https://phabricator.services.mozilla.com/D79234
