MigrateToActiveGPU is only called on compositor GLContexts, not for WebGL.
See bug 1597547 for WebGL.
After this fix, the situation can be improved in multiple ways:
- Rather than moving contexts between GPUs, it would be better to have separate
contexts for each GPU, and teach our compositors to switch a window over to
a new context.
- Instead of creating a fresh context to obtain the "preferred" GPU, we should
find the GPU that drives the display on which the context's results are going
to be displayed.
Differential Revision: https://phabricator.services.mozilla.com/D53719
--HG--
extra : moz-landing-system : lando
This method is interacting with two different locks. We have debug code that
makes sure that locking and unlocking across all locks is well-nested.
Adding this scope makes sure that we unlock mCompositingState before we unlock mViewTearDownLock.
Differential Revision: https://phabricator.services.mozilla.com/D53263
--HG--
extra : moz-landing-system : lando
This allows us to move the call to InvalidateRegionThroughoutSwapchain to just before the call to
NextSurface, which makes it easier to merge the two calls.
Differential Revision: https://phabricator.services.mozilla.com/D50877
--HG--
extra : moz-landing-system : lando
These settings are now supplied during layer creation and never change.
Consumers must now create new NativeLayer objects if they want to change size or toggle opaqueness.
This aligns the NativeLayer API with DirectComposition's capabilities. It also simplifies swap chain
management.
Differential Revision: https://phabricator.services.mozilla.com/D51757
--HG--
extra : moz-landing-system : lando
This allows us to move the call to InvalidateRegionThroughoutSwapchain to just before the call to
NextSurface, which makes it easier to merge the two calls.
Differential Revision: https://phabricator.services.mozilla.com/D50877
--HG--
extra : moz-landing-system : lando
These settings are now supplied during layer creation and never change.
Consumers must now create new NativeLayer objects if they want to change size or toggle opaqueness.
This aligns the NativeLayer API with DirectComposition's capabilities. It also simplifies swap chain
management.
Differential Revision: https://phabricator.services.mozilla.com/D51757
--HG--
extra : moz-landing-system : lando
The reason of the crash is, the window may have already been destroyed and
`PuppetWidget::mBrowserChild` was set to `nullptr` when synthesizing key event.
This patch makes `PuppetWidget::GetEditCommands()` check whether it's `nullptr`
and returns whether it's succeeded or not. Therefore, `TextInputProcessor`
can throw exception in such case.
Differential Revision: https://phabricator.services.mozilla.com/D52308
--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
Now that there is no Gecko-contributed background color in the window any more,
there's nothing that needs to be cleared away. This simplifies things.
Differential Revision: https://phabricator.services.mozilla.com/D51464
--HG--
extra : moz-landing-system : lando
With -moz-appearance: dialog now always being transparent, setting up our own
vibrant views for sheet windows is no longer necessary. We now let the regular
sheet window background show through, and that background is already vibrant.
Differential Revision: https://phabricator.services.mozilla.com/D51462
--HG--
extra : moz-landing-system : lando
The window background will be contributed by the widget itself, which renders
them underneath Gecko's rendering.
As a result, -moz-appearance: dialog is now equivalent to the combination
-moz-appearance: none; background-color: transparent.
This change does not turn the widget itself transparent because nsCocoaWindow
does not allow top level windows to become transparent (ever since bug 1162649).
If we ever add support for top level widgets with transparent backgrounds again,
we will probably want to treat -moz-appearance: dialog differently from
-moz-appearance: none; background-color: transparent, but for now this is fine.
This change means that Gecko's rendering will go into transparent buffers. This
may result in some loss of subpixel AA in various cases.
In the main browser window, there are CSS backgound colors that cover all the
non-vibrant areas of the window, so in that window we still render mostly onto
opaque pixels.
Differential Revision: https://phabricator.services.mozilla.com/D51461
--HG--
extra : moz-landing-system : lando
On macOS, the OS window always comes with an opaque background for top level
windows. This is the case even if Gecko determines the root element of the
window to be transparent: Ever since bug 1162649, nsChildView/nsCocoaWindow
ignore calls to SetTransparencyMode for top level windows and always stay opaque.
Returning true from nsChildView::WidgetPaintsBackground() lets us indicate that
we do not need an opaque backstop color to be added at the bottom of the display
list. This backstop color would interfere with vibrant -moz-appearance rendering
under the new vibrancy model.
WidgetPaintsBackground() is only called in one place, in ComputeBackstopColor():
```
nscolor PresShell::ComputeBackstopColor(nsView* aDisplayRoot) {
nsIWidget* widget = aDisplayRoot->GetWidget();
if (widget && (widget->GetTransparencyMode() != eTransparencyOpaque ||
widget->WidgetPaintsBackground())) {
// Within a transparent widget, so the backstop color must be
// totally transparent.
return NS_RGBA(0, 0, 0, 0);
}
// Within an opaque widget (or no widget at all), so the backstop
// color must be totally opaque. The user's default background
// as reported by the prescontext is guaranteed to be opaque.
return GetDefaultBackgroundColorToDraw();
}
```
On Windows 7, the widget returns eTransparencyBorderlessGlass from
GetTransparencyMode(), which also avoids the backstop color.
Differential Revision: https://phabricator.services.mozilla.com/D51458
--HG--
extra : moz-landing-system : lando
Drawing vibrancy fill colors was necessary in the past because we were erasing
the fill color that was drawn by the system, through our override of the
drawRect method of our NSVisualEffectView subclass.
However, starting with changeset be263e3d8bdfc0b6c072ffad2736999b9652d036
(from bug 1491445), we no longer override drawRect. Moreover, since the switch
to Core Animation, there is no way to clear the system's vibrancy fill drawing.
So we don't need to draw the vibrancy fill color any more. In fact, we should
stop drawing it, because now we're double-drawing it.
The fill color is very translucent so the double-drawing is not visually obvious.
Differential Revision: https://phabricator.services.mozilla.com/D51456
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
