Current code is not explicit about device recreation before session re-creation. It is actually done by nsWindow::OnPaint() before OnInProcessDeviceReset() call. But it is not explicit.
gfxWindowsPlatform::HandleDeviceReset() does d3d device re-creation if it is necessary.
Differential Revision: https://phabricator.services.mozilla.com/D130957
Originally, we would restart the GPU process a fixed number of attempts
based on the layers.gpu-process.max_restarts pref. With this patch, we
now use this pref to control how many "unstable" restarts we allow. A
restart is "stable" if and only if the process uptime exceeds the pref
layers.gpu-process.stable.min-uptime-ts and if the process renders a
total number of frames exceeding the pref
layers.gpu-process.stable.frame-threshold. This allows users to keep the
GPU process for a lot longer if they are encountering infrequent
crashes. Should the user experience the GPU process crashing quickly
and/or without rendering many frames, we will disable it as before after
a few attempts and move into the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D114531
If a user is able to get D3D11, and Software WebRender hasn't been
forced on (either by the Fission experiment or our pref), then we prefer
D3D11 in late beta and release. This will allow users who start with
D3D11 in the GPU process, to fallback to Software WebRender in the GPU
process.
Differential Revision: https://phabricator.services.mozilla.com/D114286
We can disable WebRender because the GPU process crashed, or we
encountered a graceful runtime error in WebRender. This patch adds two
new prefs to control how that fallback works.
gfx.webrender.fallback.software-d3d11 controls if WebRender falls back
to Software WebRender + D3D11 compositing. If true, and the user is
allowed to get Software WebRender, we will fallback to Software
WebRender with the D3D11 compositor first.
gfx.webrender.fallback.software controls if WebRender falls back to
Software WebRender. If true, and the user is allowed to get Software
WebRender, we will fallback to Software WebRender without the D3D11
compositor.
gfx.webrender.fallback.basic controls if WebRender or Software
WebRender falls back to Basic. If true, it falls back to Basic.
Otherwise it continues to use Software WebRender without the D3D11
compositor. Note that this means OpenGL on Android.
This patch also means that gfx.webrender.all=true and MOZ_WEBRENDER=1
no longer disables Software WebRender. It will still prefer (Hardware)
WebRender but we want to allow fallback to Software WebRender for
configurations that forced WebRender on.
Differential Revision: https://phabricator.services.mozilla.com/D103491
We can disable WebRender because the GPU process crashed, or we
encountered a graceful runtime error in WebRender. This patch adds two
new prefs to control how that fallback works.
gfx.webrender.fallback.software-d3d11 controls if WebRender falls back
to Software WebRender + D3D11 compositing. If true, and the user is
allowed to get Software WebRender, we will fallback to Software
WebRender with the D3D11 compositor first.
gfx.webrender.fallback.software controls if WebRender falls back to
Software WebRender. If true, and the user is allowed to get Software
WebRender, we will fallback to Software WebRender without the D3D11
compositor.
gfx.webrender.fallback.basic controls if WebRender or Software
WebRender falls back to Basic. If true, it falls back to Basic.
Otherwise it continues to use Software WebRender without the D3D11
compositor. Note that this means OpenGL on Android.
This patch also means that gfx.webrender.all=true and MOZ_WEBRENDER=1
no longer disables Software WebRender. It will still prefer (Hardware)
WebRender but we want to allow fallback to Software WebRender for
configurations that forced WebRender on.
Differential Revision: https://phabricator.services.mozilla.com/D103491
We can disable WebRender because the GPU process crashed, or we
encountered a graceful runtime error in WebRender. This patch adds two
new prefs to control how that fallback works.
gfx.webrender.fallback.software-d3d11 controls if WebRender falls back
to Software WebRender + D3D11 compositing. If true, and the user is
allowed to get Software WebRender, we will fallback to Software
WebRender with the D3D11 compositor first.
gfx.webrender.fallback.software controls if WebRender falls back to
Software WebRender. If true, and the user is allowed to get Software
WebRender, we will fallback to Software WebRender without the D3D11
compositor.
gfx.webrender.fallback.basic controls if WebRender or Software
WebRender falls back to Basic. If true, it falls back to Basic.
Otherwise it continues to use Software WebRender without the D3D11
compositor. Note that this means OpenGL on Android.
This patch also means that gfx.webrender.all=true and MOZ_WEBRENDER=1
no longer disables Software WebRender. It will still prefer (Hardware)
WebRender but we want to allow fallback to Software WebRender for
configurations that forced WebRender on.
Differential Revision: https://phabricator.services.mozilla.com/D103491
Lack of support of (hardware) WebRender should not block Software
WebRender support. This can happen when ANGLE isn't supported, for
example.
Differential Revision: https://phabricator.services.mozilla.com/D100445
Lack of support of (hardware) WebRender should not block Software
WebRender support. This can happen when ANGLE isn't supported, for
example.
Differential Revision: https://phabricator.services.mozilla.com/D100445
Aside from on Windows, we do not appear to handle device resets properly
without the GPU process. This patch adds in the necessary plumbing to
handle the device reset properly. It also ensures that whenever we check
for a device reset reason, we handle all of the reasons (e.g. not just
the NV video memory purge reset reason) to ensure they are not lost, and
handles them all consistently in the same manner.
It also tracks the number of device resets for thresholding purposes
with an in process compositor. While it will only disable WebRender on
Linux at this time, it will put a note in the critical log if the
threshold was exceeded on all platforms. This may prove useful in
evaluating whether or not we should do the same everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D98705
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
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
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
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
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
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
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
