Rather than just crashing, if we return a nullptr in
CreateCompatibleSurface, then we will just cause a context loss for
WebGL instances. This would be better for beta/release than just
crashing the content process on the user.
So that we can get a sense of what errors are causing this, we should
record it to the critical log. This will still crash on nightly as well
so we should get the reports.
Differential Revision: https://phabricator.services.mozilla.com/D136825
While no issues with these cases are known yet, there is no reason
why we would want this case to diverge between Wayland and X11.
Spotted by Darkspirit.
Differential Revision: https://phabricator.services.mozilla.com/D128910
This preference was requested by driver developers, simplifying
debugging processes. It is especially useful on Linux, but may
be handy on other platforms as well.
As a side effect it also ensures the two places with fallback paths
behave the same again on Android.
Depends on D128411
Differential Revision: https://phabricator.services.mozilla.com/D128592
There is only one case left where we use the `CreateConfigScreen()`
path on Linux: on Software OpenGL / `gfx.webrender.software.opengl:true`.
It is not used when using WebGL with SW-WR.
It triggers an analogous bug like the one fixed in D109737. Given
that we disable EGL on 16bit configs already, also force 32bit
in this case.
Depends on D128411
Differential Revision: https://phabricator.services.mozilla.com/D128586
`GLContextEGL::FindVisual()` currently does not work correctly for
multiple reasons. This patch:
- fixes transparency issues on Nvidia
- fixes occasional `EGL_BAD_MATCH` errors on Nvidia
- allows fixed Mesa (#149) to also use `GLContextEGL::FindVisual()`,
falling back to `GLContextGLX::FindVisual()` on older versions.
- does some cleanups that are now possible
Some context:
- When using EGL we essentially always want visuals with alpha
nowadays as we do not implement Xshape in HW Webrender. This also
matches what we do on Wayland and the performance cost is negligible
as we use opaque regions on toplevel windows.
- When using `RenderCompositorEGL` we create a global EGL context
before creating windows. Some drivers (Mesa) are very liberal about
EGL configs matching visuals, but others (Nvidia) require exact
matches.
- Nvidia places EGL configs with non-alpha visuals first, so the
current code always chooses a config for the global context that,
when calling `GLContextEGL::FindVisual()` later, results in a
non-transparent window.
- Mesa will behave similar once fixed. Currently it does not offer any
visuals with alpha.
In this patch we make sure to always pick EGL configs that have a
matching visual, i.e. one with alpha if alpha is requested for the
config.
In practice we thus always pick 32bit RGBA8888 configs and visuals.
For Mesa, where currently no such configs are provided, we continue to
provide a fallback config and use GLX to pick some visual with alpha.
This is what we already do right now and what appears to work well.
Once the fix is available, we stop using the fallback code
automatically.
Note: in theory `GLContextEGL::FindVisual()` IMO should not call
`CreateConfig()`, but rather take an existing config or context in
and then just provide the matching visual. This, however, would require
significant work with little benefit. The calls to `CreateConfig()`
should always provide the same and thus matching results.
Differential Revision: https://phabricator.services.mozilla.com/D128411
`gfxVars::UseWebRender()` now always returns `true`, thus stop passing
it around as argument. And as HW-WR unconditionally requires an alpha
channel, remove that from the code as well.
While on it, also stop requesting a depth buffer. It's not needed any
more after D113532 and D115216.
Finally, some small drive-by cleanups.
Differential Revision: https://phabricator.services.mozilla.com/D126922
`gfxVars::UseWebRender()` now always returns `true` thus stop passing
it around as argument.
At the same time, WR does not require a depth buffer any more, thus
stop requesting it when choosing a matching XVisual.
While on it, also stop requesting an alpha channel were it shouldn't
be needed. This point will require some regression testing, making
this patch 95 material.
Differential Revision: https://phabricator.services.mozilla.com/D126922
Instead of using the Wayland EGL platform. The later is very convenient
but has several limitations. Managing FBOs allows to make our code more
similar to that of MacOS as well as the Wayland software backend.
Most importantly, it will allow us to cleanly implement partial damage
by giving us direct acces to previously submitted buffers, allowing us
to blit back from them, similar like in
`NativeLayerCA::HandlePartialUpdate`.
There are several other fields where more control over buffers will
come in handy, too many to describe them here in detail.
Note: we still use individual buffer pools for each tile. However, this
change brings everything into place to allow us to change to a more
`SurfacePoolCA`-style shared pool. That will reduce GPU-memory usage.
Includes some minor cleanups here and there.
Depends on D119013
Differential Revision: https://phabricator.services.mozilla.com/D118925
Instead of using the Wayland EGL platform. The later is very convenient
but has several limitations. Managing FBOs allows to make our code more
similar to that of MacOS as well as the Wayland software backend.
Most importantly, it will allow us to cleanly implement partial damage
by giving us direct acces to previously submitted buffers, allowing us
to blit back from them, similar like in
`NativeLayerCA::HandlePartialUpdate`.
There are several other fields where more control over buffers will
come in handy, too many to describe them here in detail.
Note: we still use individual buffer pools for each tile. However, this
change brings everything into place to allow us to change to a more
`SurfacePoolCA`-style shared pool. That will reduce GPU-memory usage.
Includes some minor cleanups here and there.
Depends on D119013
Differential Revision: https://phabricator.services.mozilla.com/D118925
TextureImageEGL doesn't seem to provide any value beyond
BasicTextureImage. It's last usage was bug 814159.
Removing this has the side effect of using BasicTextureImage
for small images instead of always using TilingTextureImage.
Differential Revision: https://phabricator.services.mozilla.com/D117904
When trying to create a GLContextEGL or GLContextGLX, we should check to
see what our display is backed by. If using a software driver, we should
fail to create the context for WebRender, so that it can fallback to
Software WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D117473
After D113532, a depth-buffer is not needed any more for the draw
compositor and it was subsequently removed from the EGL and GLX
context providers in D115216. This, however, broke the experimental
Wayland native compositor integration, which still needs it.
`SurfacePoolCA` solves this by manually attaching a depth buffer in
`CreateFramebufferForTexture`. `SurfacePoolWayland` will likely be
able to do the same eventually, however until that is the case
we need the GL context to provide it.
While on it, move the hardcoded bits into a better place below the
hard-coded values for ANGLE and remove now used code to make things
less cluttered.
Context: the `aDepth` argument was introduced in D76417 for EGL on X11
support, which used `RenderCompositorOGL`. This was changed in D108508,
making X11/EGL use `RenderCompositorEGL` instead, which uses a shared
GL singleton. This again required the color depth to be independent of
the window, so 32bit color depth was hardcoded in D109737. Therefore,
the `aDepth` and other things introduced in D76417 can be removed again.
Finally, it was found that we only need 32bit depth when used with
HW-WR, see also D114959.
Differential Revision: https://phabricator.services.mozilla.com/D115760
Nowadays we often use it for Wayland, which is confusing. Also, it
has a bunch of GTK specific functions, which an alternative X11
implementation would like not have. So a explicit name is probably
deserved.
Depends on D114424
Differential Revision: https://phabricator.services.mozilla.com/D114425
Since D108508 the X11/EGL backend creates a shared GL context via
`CreateGLContextEGL()` which chains up to `CreateForCompositorWidget()`
with a `nullptr` widget. With the OGL compositor we relied on the
widget giving us a valid color depth, while now we'd fall back to
`gfxVars::ScreenDepth()`.
On X11 color depth is defined as:
> depth means the number of bits in a pixel that are actually used
> to determine the pixel color
i.e. we on a usual system we would get 24bit.
As we require an alpha channel when using WR, the result would be
disappointing. Thus hardcode 32bit color depth for X11/EGL when
creating contexts without widget for now.
In order to keep X11 and Wayland code close together, do the same
on Wayland, even if `gfxVars::ScreenDepth()` returns valid values
there.
Differential Revision: https://phabricator.services.mozilla.com/D109737
Using `dlsym` for `gdk_wayland_display_get_type` is a cleaner solution
to bug 1696319, allowing running with a GTK that lacks the Wayland
backend.
Also adds a symmetric implementation for `gdk_x11_display_get_type`,
which should help running without X11.
Differential Revision: https://phabricator.services.mozilla.com/D107406
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
Using `dlsym` for `gdk_wayland_display_get_type` is a cleaner solution
to bug 1696319, allowing running with a GTK that lacks the Wayland
backend.
Also adds a symmetric implementation for `gdk_x11_display_get_type`,
which should help running without X11.
Differential Revision: https://phabricator.services.mozilla.com/D107406
This patch enables EGL robustness with WebRender. It also tries harder
to get RBAB, favouring KHR+RBAB over EXT-RBAB, as testing with Intel and
NVIDIA Mesa drivers on Ubuntu suggests we can get KHR+RBAB but not
EXT+RBAB. It also adds support for requesting NVIDIA specific resets via
EGL_NV_robustness_video_memory_purge.
Differential Revision: https://phabricator.services.mozilla.com/D102971
KHR_partial_update allows us to avoid rerendering the entire
backbuffer every frame, and instead only render what has changed on
the current frame, as well as the difference between the current
backbuffer and the current frontbuffer. It works similarily to
EXT_buffer_age, which we already support, with the additional
requirement that we must call eglSetDamageRegion each frame before
rendering to the backbuffer.
Modify GLContextEGL::GetBufferAge() so that it queries the age if
either EXT_buffer_age or KHR_partial_update are available. This will
now automatically be queried by webrender through the
PartialPresentCompositor trait. Add a new function to that trait,
set_buffer_damage_region(), whose RenderCompositorEGL implementation
calls eglSetDamageRegion(). Call this from composite_simple(), once
the damage rect has been calculated but before rendering to the
backbuffer.
Additionally, change both RenderCompositorEGL and
RenderCompositorOGL's implementations of
ShouldDrawPreviousPartialPresentRegions() to unconditionally return
true, rather than checking for the existence of EXT_buffer_age (or
adding a new check for KHR_partial_update). The lack of these
extensions does not mean that webrender is able to skip rendering
previous frames' damage. Rather the opposite, it means we cannot
render *only* the previous frames' damage, and must instead always
render the entire buffer.
Differential Revision: https://phabricator.services.mozilla.com/D91203
KHR_partial_update allows us to avoid rerendering the entire
backbuffer every frame, and instead only render what has changed on
the current frame, as well as the difference between the current
backbuffer and the current frontbuffer. It works similarily to
EXT_buffer_age, which we already support, with the additional
requirement that we must call eglSetDamageRegion each frame before
rendering to the backbuffer.
Modify GLContextEGL::GetBufferAge() so that it queries the age if
either EXT_buffer_age or KHR_partial_update are available. This will
now automatically be queried by webrender through the
PartialPresentCompositor trait. Add a new function to that trait,
set_buffer_damage_region(), whose RenderCompositorEGL implementation
calls eglSetDamageRegion(). Call this from composite_simple(), once
the damage rect has been calculated but before rendering to the
backbuffer.
Additionally, change both RenderCompositorEGL and
RenderCompositorOGL's implementations of
ShouldDrawPreviousPartialPresentRegions() to unconditionally return
true, rather than checking for the existence of EXT_buffer_age (or
adding a new check for KHR_partial_update). The lack of these
extensions does not mean that webrender is able to skip rendering
previous frames' damage. Rather the opposite, it means we cannot
render *only* the previous frames' damage, and must instead always
render the entire buffer.
Differential Revision: https://phabricator.services.mozilla.com/D91203