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
If GL is threadsafe, we can run on the compositor thread. This appears
to have performance benefits, possibly because the renderer thread is
too busy. If GL is not threadsafe, we must run the WebGL OOP instances
on the renderer thread.
At the time of writing, only the nouveau drivers on Linux are considered
to be not threadsafe, so most users will see WebGL running on the
compositor thread. This patch also adds prefers to override the
blocklist to either assume GL is threadsafe
(webgl.threadsafe-gl.force-enabled) and not threadsafe
(webgl.threadsafe-gl.force-disabled).
Differential Revision: https://phabricator.services.mozilla.com/D130634
This patch adds the necessary IPDL plumbing to allow us to create WebGL
instances off the main thread in the content process, and to execute
them on the Renderer thread in the compositor process.
Differential Revision: https://phabricator.services.mozilla.com/D127839
This may be another source of failing OOP iframe document print. I will try to
see whether it can be reproducible locally later.
Differential Revision: https://phabricator.services.mozilla.com/D121075
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
This extends on the changes in part 12a and consumes the new PortRef-based API
in all existing process types other than the fork server. The IPDL C++ unit
tests were already broken before this change, and were not updated.
Differential Revision: https://phabricator.services.mozilla.com/D112777
This extends on the changes in part 12a and consumes the new PortRef-based API
in all existing process types other than the fork server. The IPDL C++ unit
tests were already broken before this change, and were not updated.
Differential Revision: https://phabricator.services.mozilla.com/D112777
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
This is just cleanup while I was looking at why the test still fails
sometimes locally even with my patch. It is a bit racy because
BrowserChild's visible rect is not set by the time we do the
cross-process paint, so we clip everything...
This doesn't affect users and I have some upcoming PTO though, so will
look into it when I'm back.
Differential Revision: https://phabricator.services.mozilla.com/D116924
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
Removes the PPluginSurface actor used for windowed plugins, as part of removing all of NPAPI plugin support. SharedDIB is then unused and is also removed.
Differential Revision: https://phabricator.services.mozilla.com/D107140
Removes the PPluginSurface actor used for windowed plugins, as part of removing all of NPAPI plugin support. SharedDIB is then unused and is also removed.
Differential Revision: https://phabricator.services.mozilla.com/D107140
Before we start a resource update, we should check if we are virtual
memory pressured (32-bit Windows only). If so, pre-emptively unmap
shared surfaces until the pressure is relieved to try to avoid OOMs
elsewhere. This only applies to the GPU process because the parent
process actively watches its own memory pressure and dispatches a
low-memory event which our expiration tracker is an observer for.
Differential Revision: https://phabricator.services.mozilla.com/D109441
Before we start a resource update, we should check if we are virtual
memory pressured (32-bit Windows only). If so, pre-emptively unmap
shared surfaces until the pressure is relieved to try to avoid OOMs
elsewhere. This only applies to the GPU process because the parent
process actively watches its own memory pressure and dispatches a
low-memory event which our expiration tracker is an observer for.
Differential Revision: https://phabricator.services.mozilla.com/D109441
Before we start a resource update, we should check if we are virtual
memory pressured (32-bit Windows only). If so, pre-emptively unmap
shared surfaces until the pressure is relieved to try to avoid OOMs
elsewhere. This only applies to the GPU process because the parent
process actively watches its own memory pressure and dispatches a
low-memory event which our expiration tracker is an observer for.
Differential Revision: https://phabricator.services.mozilla.com/D109441