eWindowType_child type is outdated on Linux and should not be used. It uses widget hierarchy based on GdkWindow and has its limitations.
Let's use popup types instead with proper config and widget hierarchy.
Differential Revision: https://phabricator.services.mozilla.com/D128623
Now that transparency is properly supported on Nvidia, remove
the workaround for non-transparent popups again.
Depends on D128411
Differential Revision: https://phabricator.services.mozilla.com/D128540
`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
mScheduledTask means scheduled task. When there's nothing sheduled we look inactive but that's not correct.
Let's remove that check as it was before.
Differential Revision: https://phabricator.services.mozilla.com/D128488
This makes it easier to tweak logs by e.g. prepending strings as needed,
and is also less ugly over all.
Also added a few missing includes to fix non-unified builds while at it.
Differential Revision: https://phabricator.services.mozilla.com/D128264
Synced FlushRendering() causes deadlock on Wayland.
Main thread is blocked at MessageChannel::WaitForSyncNotify() and it's not processing events from system.
Rendering thread is blocked at RendererOGL::UpdateAndRender() / eglQuerySurface(). Mesa is waiting for free back buffer
at get_back_bo(), it's spinning wl_display_roundtrip_queue() and waiting for free buffer but it doesn't get one as main loop is blocked.
Differential Revision: https://phabricator.services.mozilla.com/D127878
Right now we resize/move popup windows even when move-to-rect callback is pending which leads to wrong popup
position / size if popup is moved/resized repeatedly.
In this patch we do:
- Remove multiple move/resize internal routines (NativeMove(), NativeResize()) and use only one method NativeMoveResize() for both.
- Always use NativeMoveResizeWaylandPopup() for popup window positioning and check if we're waiting to move-to-rect callback.
- When we're waiting to the callback save both new size and position (previously we saved size only) and use mBounds coordinates for it.
- Remove position/size params from NativeMoveResize() / NativeMoveResizeWaylandPopup() and use mBounds internally and mBounds is already
set and it's correct popup size/position.
- Remove extra DispatchResized() call - it's already called from NativeMoveResize().
Differential Revision: https://phabricator.services.mozilla.com/D127662
`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
This patch adds plumbing to keep track of why we request frames to be rendered.
This information is then displayed in gecko profile markers on the renderer thread as well as in profiler HUD counters (See "Render reasons" in profiler.rs).
Differential Revision: https://phabricator.services.mozilla.com/D127274
`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
Currently child windows do not show up in this configuration and it's
not clear yet what the root cause of the issue is.
As we want to ship X11/EGL by default in 94, work around the issue
for now.
Differential Revision: https://phabricator.services.mozilla.com/D127264
Wayland/Gtk sets drag state right after drag_motion event only.
While we're reading data for child process we're getting 'drag_motion' events from nested loop.
We don't know the final D&D state yet as we need reply from the child process.
When we set the D&D state latter, it's ignored by Gtk and D&D is considered as
canceled by client.
Right now we explicitly state 'drag denied' after D&D start until we have a reply from child process.
We're changing it to 'drag accepted' on Wayland until we have a reply from child process
and we also send the reply in WindowDragMotionHandler() to fulfill Wayland protocol needs.
It does not change final D&D state - we get the data only when child process requests it.
Differential Revision: https://phabricator.services.mozilla.com/D126226
Wayland/Gtk sets drag state right after drag_motion event only.
While we're reading data for child process we're getting 'drag_motion' events from nested loop.
We don't know the final D&D state yet as we need reply from the child process.
When we set the D&D state latter, it's ignored by Gtk and D&D is considered as
canceled by client.
Right now we explicitly state 'drag denied' after D&D start until we have a reply from child process.
We're changing it to 'drag accepted' on Wayland until we have a reply from child process
and we also send the reply in WindowDragMotionHandler() to fulfill Wayland protocol needs.
It does not change final D&D state - we get the data only when child process requests it.
Differential Revision: https://phabricator.services.mozilla.com/D126226
When we get data from D&D operation by nsWindow::OnDragDataReceivedEvent, speed up data transfer to child process by
WindowDragMotionHandler() call.
Differential Revision: https://phabricator.services.mozilla.com/D126211
We sometimes miss reply to D&D motion event due to delayed DnsDragService::RunScheduledTask() call.
We can't call D&D handler directly from drag-motion event as it causes nested recursions and re-entrance
in glib loop so use higher priority for the delayed handler call at least.
Disable re-entrance of nsDragService::RunScheduledTask() which may happen when
we get D&D data from drag_drop event.
Provide more loggig to D&D code.
Differential Revision: https://phabricator.services.mozilla.com/D126182
When we position noautohide popup we can't use xdg_positioner as the popup
is rendered aside popup hierarchy and can be closed by user interaction only.
Try to keep the popup on screen by just moving it in scope of
it's parent window.
Differential Revision: https://phabricator.services.mozilla.com/D124909
On Wayland gdk_window_input_shape_combine_region() call is cached and applied to underlying wl_surface when GdkWindow is repainted.
Force repaint of GdkWindow at nsWindow::SetWindowMouseTransparent() to apply the changes immediately.
Differential Revision: https://phabricator.services.mozilla.com/D124256
To ensure we don't freeze when the compositing state changes and
makes a similar call in `Create()` redundant.
Note: we can't do this in `OnCompositedChanged()` as it gets called
too early.
Differential Revision: https://phabricator.services.mozilla.com/D123792
This works, but there's an issue dealing with dynamic changes. I'm
almost sure that's a GTK issue, will try to file and repro.
Differential Revision: https://phabricator.services.mozilla.com/D122584
