We use MOZ_WEBRENDER to force WebRender on in our testing
infrastructure. We may silently fallback to basic during our tests if we
encounter an error and the test may pass as a result. It would be best
if we asserted we don't lose WebRender while testing.
Differential Revision: https://phabricator.services.mozilla.com/D97004
If we don't disable hardware acceleration when we lose WebRender, we
will likely fallback to OpenGL compositing. This is not a supported
configuration. We already do this step if we decide against using
WebRender during configuration, but not if it was lost at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D97355
Use ID3D11VideoProcessor for video frame rendering.
WebRenderError::VIDEO_OVERLAY does not cause disabling WebRender. It just change gfxVars::UseWebRenderDCompVideoOverlayWin() to false.
Differential Revision: https://phabricator.services.mozilla.com/D88763
We don't know why we see initialization failures in the telemetry which
makes it hard to investigate why users aren't getting WebRender and
instead fallback to basic. Let's expose the detailed error message
WebRender already generates and puts in the critical log.
Differential Revision: https://phabricator.services.mozilla.com/D89185
Change GPUProcessManager::OnPreferenceChange() and
RDDProcessManager::OnPreferenceChange() to only queue preference changes when
the child process is in the act of launching. And don't start observing
preference changes until we launch the child process rather that at startup.
Differential Revision: https://phabricator.services.mozilla.com/D62112
--HG--
extra : moz-landing-system : lando
CompositorWidgetChild is about to be responsible for creating,
destroying, and presenting a shared buffer that CompositorWidgetParent
will draw into. To do this, it will need the window handle,
transparency mode changes, window size changes, and window size mode
changes.
Its creation is also about to become fallible, so it needs a separate
initialization routine.
Differential Revision: https://phabricator.services.mozilla.com/D57430
--HG--
extra : moz-landing-system : lando
PlatformCompositorWidgetDelegate was meant to be a pure virtual base
class for all the functions that nsWindow could call that would
either go to an in-process compositor widget or an OMTC widget.
By that definition, it does not seem like CompositorWidgetParent should
be a subclass, since nsWindow cannot directly call its methods and
currently CompositorWidgetParent has several "do nothing"
implementations of the interface methods because they don't really
belong.
This changeset remedies this by refactoring CompositorWidgetParent so
it is no longer an implementor of PlatformCompositorWidgetDelegate. Now
the only implementors are CompositorWidgetChild and InProcessWin-
CompositorWidget, which makes sense because they are both directly
called through the nsWindow delegate.
It also eliminates some of the methods that seem like they don't belong
in PlatformCompositorWidgetDelegate.
Differential Revision: https://phabricator.services.mozilla.com/D57429
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
When double buffering is enable with compositor, DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL is used without DirectComposition. There are some devices that swap chain with DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL does not work well. In this case, device reset happens very often. To avoid the situation, the double buffering needs to be disabled when device reset happens.
Differential Revision: https://phabricator.services.mozilla.com/D36579
--HG--
extra : moz-landing-system : lando
This also removes the following prefs, because they're unused:
- media.autoplay.allow-muted pref
- media.autoplay.blackList-override-default
Differential Revision: https://phabricator.services.mozilla.com/D36396
--HG--
extra : rebase_source : 0570540496302b3efedadf4d5115ee5422d5c279
The patch also removes the layers.mlgpu.enable-container-resizing pref, because
it's dead.
Differential Revision: https://phabricator.services.mozilla.com/D36159
--HG--
extra : rebase_source : e215d584aed18f865d2e8d00a78e76e9b0323e6e
On android, android's nsWindow creates LayerManaer only in nsWindow::Create(). When WebRender error happened, gecko just stopped rendering by disabling Webrender.
The nsWindow needs to re-create LayerManager during disabling Webrender. Further, during disabling WebRender, All GeckoSurfaceTextures should not be attached to GLContext. It is for preventing a conflict with AttachToGLContext() call in SurfaceTextureHost::EnsureAttached().
Differential Revision: https://phabricator.services.mozilla.com/D26687
--HG--
extra : moz-landing-system : lando
If the GPU process becomes disabled due to crashes, then we should not
allow Linux to fallback from WebRender to OpenGL compositing in the
parent process. It should instead fallback to software just like
Windows. This is important because we don't support the OpenGL
compositor configuration.
Differential Revision: https://phabricator.services.mozilla.com/D34360
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
--HG--
extra : moz-landing-system : lando
gfxPrefs Live preferences are almost identical to StaticPrefs.
We leave aside for now those that set a custom change callback as this feature isn't yet supported in StaticPrefs.
Differential Revision: https://phabricator.services.mozilla.com/D31256
--HG--
extra : moz-landing-system : lando
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
--HG--
extra : moz-landing-system : lando
CompositorManagerParent::sInstance is not set in GPU process. It is necessary to send NotifyWebRenderError message.
Differential Revision: https://phabricator.services.mozilla.com/D28452
--HG--
extra : moz-landing-system : lando
When the compositor thread has begun shutdown, it will spin the event
loop for the main thread until the last CompositorThreadHolder reference
has been released. While spinning, new IPDL objects may be attempted to
be created which depend on the compositor thread; we should check to
ensure the compositor thread is still around before proceeding with
creation. These objects include CompositorManagerParent,
ImageBridgeParent, and VRManagerParent. Additionally there is a very
similar bug between the vsync thread and VsyncBridgeChild.
Differential Revision: https://phabricator.services.mozilla.com/D23308
Bogdan Tara
Andrew Osmond
Simon Giesecke
Bob Owen
Jeff Muizelaar
sotaro
Andrew McCreight
Botond Ballo
Haik Aftandilian
shindli
Chris Martin
Sylvestre Ledru
Dan Glastonbury
Razvan Maries
Nika Layzell
Nicholas Nethercote
Brindusan Cristian
Jean-Yves Avenard
Gurzau Raul
Matt Woodrow
Ryan Hunt
Alex Gaynor