Vector reallocations in CompositeState::push_surface are taking about 2% of total frame building time before this patch. There was an effort at preallocating some with constant values but I suspect these constants haven't been updated along with picture cachign heuristics.
Differential Revision: https://phabricator.services.mozilla.com/D80195
This patch a simple utility to help with pre-allocating vectors that we can't recycle and use it with the primitive headers.
Differential Revision: https://phabricator.services.mozilla.com/D80194
Bug 1592038 implemented a means for reducing memory usage resulting from needlessly
duplicated allocation of depth buffers when rendering WR picture cache tiles via
the NativeLayer interface. This aims to keep a similarly level of memory savings
even when using NativeLayer + SWGL.
SWGL allows, as an extension beyond OpenGL, specifying an allocation size separate
from the incidental size of a texture, which can be used to render to a smaller
valid rect of a texture without continually reallocating it every time the size
of the valid rect changes within the actual tile size. This functionality is used
to keep around only a single depth texture for the SWGL compositor that is resized
to accommodate the maximum requested tile size, so that any surface or tile can
use it as desired.
Differential Revision: https://phabricator.services.mozilla.com/D80274
Currently RendererOGL has mixed-in details of SWGL context creation which becomes messy
and slightly unanticipated based on the nomenclature and structure of RendererOGL. Based
on other work in bug 1646835, it becomes more natural to move this context creation into
the specific SWGL RenderCompositors so that RendererOGL can be agnostic to any SWGL
details.
Differential Revision: https://phabricator.services.mozilla.com/D80273
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
