Per Microsoft documentation, DXGI_SCALING_NONE is only supported by
swap chains using DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL; for any other swap
effect, including DXGI_SWAP_EFFECT_SEQUENTIAL, another value must be
supplied. Prior to Windows 10 the only such available entry was
DXGI_SCALING_STRETCH, so use that.
This causes the `CreateSwapChainForHwnd` call to succeed, rather than
causing us to fall back to `CreateSwapChain`. There is no known user-
facing effect here, as DXGI_SCALING_STRETCH is documented to be the
semantics applied by `CreateSwapChain` -- but it does eliminate an error
message from the D3D11 debug layer's output.
Differential Revision: https://phabricator.services.mozilla.com/D171521
Per Microsoft documentation, DXGI_SCALING_NONE is only supported by
swap chains using DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL; for any other swap
effect, including DXGI_SWAP_EFFECT_SEQUENTIAL, another value must be
supplied. Prior to Windows 10 the only such available entry was
DXGI_SCALING_STRETCH, so use that.
This causes the `CreateSwapChainForHwnd` call to succeed, rather than
causing us to fall back to `CreateSwapChain`. There is no known user-
facing effect here, as DXGI_SCALING_STRETCH is documented to be the
semantics applied by `CreateSwapChain` -- but it does eliminate an error
message from the D3D11 debug layer's output.
Differential Revision: https://phabricator.services.mozilla.com/D171521
Destroy RenderBufferTextureHosts that use VideoBridgeParent's Shmems before destroying all VideoBridgeParent's Shmems by PVideoBridgeParent::OnChannelError().
Differential Revision: https://phabricator.services.mozilla.com/D169796
Mingw's dcomp.h is not the official one, but rather a by-hand
reproduction. While this newly-updated version has e.g.
IDCompositionFilterEffect, it is still missing e.g.
IDCompositionColorMatrixEffect.
Differential Revision: https://phabricator.services.mozilla.com/D168839
+ Add gfx.color_management.rec709_gamma_as_srgb:true. :'(
In particular, rec709(16/255) -> srgb(31/255). Even though it's
technically correct, it's practically-speaking incorrect, since that's
not what Chrome does, nor what the web expected for years and years.
In practice, basically everyone expects gamma to just be completely
ignored.
What people expect:
* Pretend gamut is srgb(==rec709), but stretch this naively for the
display. If you have a display-p3-gamut display, srgb:0.5 expects to
be displayed as display:0.5, which will be display-p3:0.5 to the eyes.
* Pretend all content gammas (TFs) are srgb(!=rec790), and then bitcast this
naively for the display. E.g. rec709(16/255) should
display the same as srgb(16/255), not srgb(31/255). (Note: display-p3
uses srgb gamma) But if your display has e.g. gamma=3.0, don't
convert or compensate.
This is a formalization of what you get when you spend decades ignoring
color management, and people build things based on behavior-in-practice,
not behavior-in-theory.
Also:
+ gfx.color_management.native_srgb:true for Windows, so we don't use the
display color profile, which no one else does.
+ Add rec2020_gamma_as_rec709, so we have a path towards maybe having
rec2020 use its correct transfer function, rather than srgb (like
rec709).
Differential Revision: https://phabricator.services.mozilla.com/D161857
There were cases that mVideoSwapChain->Present() took long time. It caused low fps and stuttering and lots of dropped frames. When it happens, disabling video overlay could address the problem.
Differential Revision: https://phabricator.services.mozilla.com/D171039
LibX11 versions prior to 1.7 have a race condition that made it unsafe to use
in multiple threads. Since Firefox 104, we created a CanvasRender thread that
is used to service WebGL commands off the Renderer thread so that WebGL does
not block WebRender. If WebGL uses GLX, this can lead us to using GLX on the
two different threads. In combination with an unsafe version of libX11, this
can lead to severe instability.
Further evidence points to the fact that the fix in 1.7 may have caused further
crashes that were not resolved until 1.7.4. Yet other reports indicate other
drivers than Mesa may still have issues even after 1.7.4. Ultimately, there
may be no safe version of libX11 to use right now.
However, GLX, which uses libX11, is considered legacy at this point, with many
users transitioning to EGL instead. It seems reasonable to not allow GLX to be
used from multiple threads at all, unless overridden by a pref, to work around
this.
We already have a FEATURE_THREADSAFE_GL in place to denote this, which was
currently used mainly for Nouveau which is also unsafe to use on multiple
threads. If this feature fails, the CanvasRender thread is not used, and
all WebGL commands go back to being on the Renderer thread as normal, avoiding
the problem.
A further snag is that recent ANGLE updates required a larger CanvasRenderer
thread stack size to avoid exhausting the stack. This patch uncovers the fact
that the Renderer and Compositor threads did not similarly have their stack
sizes adjusted in case WebGL is running on those threads instead.
Differential Revision: https://phabricator.services.mozilla.com/D170992
LibX11 versions prior to 1.7 have a race condition that made it unsafe to use
in multiple threads. Since Firefox 104, we created a CanvasRender thread that
is used to service WebGL commands off the Renderer thread so that WebGL does
not block WebRender. If WebGL uses GLX, this can lead us to using GLX on the
two different threads. In combination with an unsafe version of libX11, this
can lead to severe instability.
Further evidence points to the fact that the fix in 1.7 may have caused further
crashes that were not resolved until 1.7.4. Yet other reports indicate other
drivers than Mesa may still have issues even after 1.7.4. Ultimately, there
may be no safe version of libX11 to use right now.
However, GLX, which uses libX11, is considered legacy at this point, with many
users transitioning to EGL instead. It seems reasonable to not allow GLX to be
used from multiple threads at all, unless overridden by a pref, to work around
this.
We already have a FEATURE_THREADSAFE_GL in place to denote this, which was
currently used mainly for Nouveau which is also unsafe to use on multiple
threads. If this feature fails, the CanvasRender thread is not used, and
all WebGL commands go back to being on the Renderer thread as normal, avoiding
the problem.
A further snag is that recent ANGLE updates required a larger CanvasRenderer
thread stack size to avoid exhausting the stack. This patch uncovers the fact
that the Renderer and Compositor threads did not similarly have their stack
sizes adjusted in case WebGL is running on those threads instead.
Differential Revision: https://phabricator.services.mozilla.com/D170992
- Get widget size in RenderCompositorSWGL::BeginFrame() and save it for further use. That prevents flickering/artifacts if compositor widget size is changed during rendering.
- Request full screen update when widget size changes on Wayland.
Differential Revision: https://phabricator.services.mozilla.com/D169905
- Get widget size in RenderCompositorSWGL::BeginFrame() and save it for further use. That prevents flickering/artifacts if compositor widget size is changed during rendering.
- Request full screen update when widget size changes on Wayland.
Differential Revision: https://phabricator.services.mozilla.com/D169905
Mingw's dcomp.h is not the official one, but rather a by-hand
reproduction. While this newly-updated version has e.g.
IDCompositionFilterEffect, it is still missing e.g.
IDCompositionColorMatrixEffect.
Differential Revision: https://phabricator.services.mozilla.com/D168839
+ Add gfx.color_management.rec709_gamma_as_srgb:true. :'(
In particular, rec709(16/255) -> srgb(31/255). Even though it's
technically correct, it's practically-speaking incorrect, since that's
not what Chrome does, nor what the web expected for years and years.
In practice, basically everyone expects gamma to just be completely
ignored.
What people expect:
* Pretend gamut is srgb(==rec709), but stretch this naively for the
display. If you have a display-p3-gamut display, srgb:0.5 expects to
be displayed as display:0.5, which will be display-p3:0.5 to the eyes.
* Pretend all content gammas (TFs) are srgb(!=rec790), and then bitcast this
naively for the display. E.g. rec709(16/255) should
display the same as srgb(16/255), not srgb(31/255). (Note: display-p3
uses srgb gamma) But if your display has e.g. gamma=3.0, don't
convert or compensate.
This is a formalization of what you get when you spend decades ignoring
color management, and people build things based on behavior-in-practice,
not behavior-in-theory.
Also:
+ gfx.color_management.native_srgb:true for Windows, so we don't use the
display color profile, which no one else does.
+ Add rec2020_gamma_as_rec709, so we have a path towards maybe having
rec2020 use its correct transfer function, rather than srgb (like
rec709).
Differential Revision: https://phabricator.services.mozilla.com/D161857
+ Add gfx.color_management.rec709_gamma_as_srgb:true. :'(
In particular, rec709(16/255) -> srgb(31/255). Even though it's
technically correct, it's practically-speaking incorrect, since that's
not what Chrome does, nor what the web expected for years and years.
In practice, basically everyone expects gamma to just be completely
ignored.
What people expect:
* Pretend gamut is srgb(==rec709), but stretch this naively for the
display. If you have a display-p3-gamut display, srgb:0.5 expects to
be displayed as display:0.5, which will be display-p3:0.5 to the eyes.
* Pretend all content gammas (TFs) are srgb(!=rec790), and then bitcast this
naively for the display. E.g. rec709(16/255) should
display the same as srgb(16/255), not srgb(31/255). (Note: display-p3
uses srgb gamma) But if your display has e.g. gamma=3.0, don't
convert or compensate.
This is a formalization of what you get when you spend decades ignoring
color management, and people build things based on behavior-in-practice,
not behavior-in-theory.
Also:
+ gfx.color_management.native_srgb:true for Windows, so we don't use the
display color profile, which no one else does.
+ Add rec2020_gamma_as_rec709, so we have a path towards maybe having
rec2020 use its correct transfer function, rather than srgb (like
rec709).
Differential Revision: https://phabricator.services.mozilla.com/D161857
Implementation is borrowed from RenderAndroidSurfaceTextureHost. Since Android SurfaceTexture and AndroidHardwareBuffer use same android GraphicBuffer.
Differential Revision: https://phabricator.services.mozilla.com/D168764
2 problems existed.
- [1] RenderAndroidSurfaceTextureHost::GetUvCoords() was not called when RenderAndroidSurfaceTextureHost is wrapped by RenderTextureHostWrapper.
- [2] NeedsYFlip() of SurfaceTextureHost::CreateRenderTexture() uses TextureHost::mFlags. But TextureHost::mFlags was updated by RemoteTextureHostWrapper::ApplyTextureFlagsToRemoteTexture() after SurfaceTextureHost::CreateRenderTexture() call. Then RenderAndroidSurfaceTextureHost::mOriginPos became wrong.
[1] is addressed by adding RenderTextureHostWrapper::GetUvCoords()
[2] is addressed by removing RenderAndroidSurfaceTextureHost::mOriginPos. It is not necessary since Bug 1731980.
Differential Revision: https://phabricator.services.mozilla.com/D168763
+ Add gfx.color_management.rec709_gamma_as_srgb:true. :'(
In particular, rec709(16/255) -> srgb(31/255). Even though it's
technically correct, it's practically-speaking incorrect, since that's
not what Chrome does, nor what the web expected for years and years.
In practice, basically everyone expects gamma to just be completely
ignored.
What people expect:
* Pretend gamut is srgb(==rec709), but stretch this naively for the
display. If you have a display-p3-gamut display, srgb:0.5 expects to
be displayed as display:0.5, which will be display-p3:0.5 to the eyes.
* Pretend all content gammas (TFs) are srgb(!=rec790), and then bitcast this
naively for the display. E.g. rec709(16/255) should
display the same as srgb(16/255), not srgb(31/255). (Note: display-p3
uses srgb gamma) But if your display has e.g. gamma=3.0, don't
convert or compensate.
This is a formalization of what you get when you spend decades ignoring
color management, and people build things based on behavior-in-practice,
not behavior-in-theory.
Also:
+ gfx.color_management.native_srgb:true for Windows, so we don't use the
display color profile, which no one else does.
+ Add rec2020_gamma_as_rec709, so we have a path towards maybe having
rec2020 use its correct transfer function, rather than srgb (like
rec709).
Differential Revision: https://phabricator.services.mozilla.com/D161857
This will be needed by the draw compositor which can't own the device renderer's device but needs to use it. Other implementations can just ignore the parameter.
Differential Revision: https://phabricator.services.mozilla.com/D165958
Now that we're using `EGL_KHR_no_config_context`, this attribute request is no longer necessary.
Even worse, support for it already been removed by upstream ANGLE. So, let's remove it before we try
to upgrade ANGLE.
Differential Revision: https://phabricator.services.mozilla.com/D167038
This was interesting enough that @jgilbert wanted this, so I'm including this for completeness in
the current patch stack.
Split out from @jgilbert's D164308.
Differential Revision: https://phabricator.services.mozilla.com/D166709
When available, we should use the [`EGL_KHR_no_config_context` extension] inside of
`GLContextEGL::CreateEGLPBufferOffscreenContext`. The usage of this extension will be necessary to
accommodate incoming upstream changes in ANGLE, which have [migrated away][incoming-breakage] from
[our usage of `EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE` in
`gfx/webrender_bindings/RenderCompositorANGLE.cpp`][what-will-be-broken] in favor of this standard
extension. Luckily it's forwards-compatible to start consuming it now!
This revision changes a few things that are linked:
- Separate assignment and usage of a surface context from that of a context.
- Rename `GLContextEGL::mConfig` to `mSurfaceConfig` to better reflect its usage; it's only ever
used to create surfaces, not contexts.
Split out from @jgilbert's D164308 and D164309.
[`EGL_KHR_no_config_context` extension]: https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_no_config_context.txt
[incoming-breakage]: ad8e4d99a9
[what-will-be-broken]: https://searchfox.org/mozilla-central/rev/b19830c6b22f73758862d34d2c64f57735890e90/gfx/webrender_bindings/RenderCompositorANGLE.cpp#668
Differential Revision: https://phabricator.services.mozilla.com/D166708
