Open Bug 1861980 Opened 1 year ago Updated 2 months ago

[Gtk3] Investigate Gtk toolkit removal for window rendering

Categories

(Core :: Widget: Gtk, enhancement, P5)

Product:
Core
Component:
Widget: Gtk
Type:
enhancement

Tracking

()

People

(Reporter: stransky, Unassigned)

References

Details

Attachments

(2 files)

wl_surface screenshot
366.05 KB, image/png
Details
experimental-wayland.patch
101.81 KB, patch
Details | Diff | Splinter Review

Along Firefox port to Gtk4 we may also investiate possibility to remove Gtk toolkit completely (at least for window rendering) and talk to Wayland directly here.

This may probably break ATK code integration and also theming. May need handling of CSD decorations and so on.

Advantage may be subsurface removal and possibility to better handle popups which are broken in Gtk3.

Summary: Investigate Gtk toolkit removal → Investigate Gtk toolkit removal for window rendering
Flags: needinfo?(stransky)

I think leaving X11 on GTK3 and writing a new native Wayland backend is indeed the best way forward, all things considered. I'd also be interested in helping with this.

Additionally to the already mentioned areas, I can think of a couple more where a new backend would help:

  1. moving Wayland socket polling into a dedicated thread
  2. significantly simplify usage of further subsurfaces, such as for video offloading
  3. likely end up having less lines of code / less complexity than the current gtk backend...
See Also: → 1743144

(In reply to Robert Mader [:rmader] from comment #1)

I think leaving X11 on GTK3 and writing a new native Wayland backend is indeed the best way forward, all things considered. I'd also be interested in helping with this.

I'm not thinking about something such radical. I think custom widget implementation with custom drawing implementation without Gdk internals (if that's even possible) may be a viable first step.

  1. significantly simplify usage of further subsurfaces, such as for video offloading

Can you be more specific here? We can surely implement subsurfaces for video playback (video overlay) on recent scenario without any issue.

Flags: needinfo?(stransky)

(In reply to Robert Mader [:rmader] from comment #1)

  1. moving Wayland socket polling into a dedicated thread

AFAIK that can be also done along GTK - nobody forces us to use build-in event loop. We can implement our own and just process gtk events along too.

I'm not thinking about something such radical. I think custom widget implementation with custom drawing implementation without Gdk internals (if that's even possible) may be a viable first step.

Oh, sorry, I guess I read more into the title :P But I think it's a worthy discussion to be had, at least in the long run.

Can you be more specific here? We can surely implement subsurfaces for video playback (video overlay) on recent scenario without any issue.

In particular the need for gdk_wayland_window_add_frame_callback_surface() - it made things more error prone when implementing the compositor backend and also adds overhead. But in general my impression is that the extra subsurface comes at quite a cost, complexity wise.

AFAIK that can be also done along GTK - nobody forces us to use build-in event loop. We can implement our own and just process gtk events along too.

Can we? I'm not aware of a possibility - but it would be great and definitely worth investigating!

gdk_wayland_window_add_frame_callback_surface()

I'd very much like to avoid adding such APIs to GTK4, as we'd need to keep them working and that limits refactoring abilities.

custom widget implementation with custom drawing implementation without Gdk internals

I think that is pretty impossible, especially because we're in the process of integrating the rendering deeper and deeper GDK.
While with early GTK4, there was a somewhat decent separation between GDK and GSK, this is less and less true today. The rendering code needs to configure fractional scaling, HDR, bit depth and all these things.

On top of that, GTK is constantly at odds with the GL and Vulkan WSI (usually about which wl_surface properties are managed by GL/Vulkan and which ones aren't), so there's custom code required that depends on which rendering method GTK uses - and GTK decides that dynamically at startup, with a switch to Vulkan as default entirely possible during 4.x

(In reply to Benjamin Otte from comment #5)

custom widget implementation with custom drawing implementation without Gdk internals

I think that is pretty impossible, especially because we're in the process of integrating the rendering deeper and deeper GDK.
While with early GTK4, there was a somewhat decent separation between GDK and GSK, this is less and less true today. The rendering code needs to configure fractional scaling, HDR, bit depth and all these things.

On top of that, GTK is constantly at odds with the GL and Vulkan WSI (usually about which wl_surface properties are managed by GL/Vulkan and which ones aren't), so there's custom code required that depends on which rendering method GTK uses - and GTK decides that dynamically at startup, with a switch to Vulkan as default entirely possible during 4.x

I mean to do such changes for recent Gtk3 implementation if that's even possible.

Summary: Investigate Gtk toolkit removal for window rendering → [Gtk3] Investigate Gtk toolkit removal for window rendering

This may probably break ... theming.

Here's my two cents on the theming point:
Firefox has a perfectly working lwtheme appearance 'engine' thingy as-is, and this bug report's solution would involve expanding that 'engine' into a full-blown control set rather than its currently partial control set state.

Here's what I would suggest to complement this:

  1. Consider initially keeping GTK around for the sole purpose of obtaining its colour palette when in System Theme, so that you can stick said colour palette onto lwtheme on demand - any other uses of GTK should be completely removed from Firefox as per this issue's solution-ideas, including inside the legacy windows (Library window, confirmation dialog for Browser Toolbox, etc.).
  2. Add a setting to about:config to disable using GTK's colour palette - when on, System Theme will use Light or Dark respectively depending on dark mode preference, just like it does for all other platforms.

On GNOME, the about:config setting mentioned on suggestion number 2 should be exclusively pre-enabled by default, kinda like how the CSD mode option was initially exclusively pre-enabled on a limited set of Desktop Environments.
Meanwhile, on KDE Plasma this would allow GTK stylesheets like Breeze to maintain their ability to style Firefox to match the system colour palette - in many ways, it wouldn't be all that different to how Chromium's Qt theme currently works on Chromium's upper browser chrome if implemented this way.

The idea here is that you could still retain a critical aspect of System Theming, by getting GTK3's colour palette and applying it onto a complete-control-set lwtheme, in the meantime until you implement a better alternative of getting the system colour palette (which could then hopefully auto-refresh whenever the colour palette is changed), all while still fixing this issue at hand and the many remaining issues with your GTK3 stylesheet integration.
Firefox has been moving towards only using GTK for its colour palette steadily with the past versions of Firefox - it's time Firefox fully embraces that, to be honest.

I want to contribute to this bug so my goal is to try to remove the use of GtkWindow on Wayland and to use pure wl_surface for each window. For the moment I get the rendering done in a wl_surface created on my own and leave the GtkWindow empty (border and shadow but no content). I am also able to get wayland compositor mouse move event on this surface and dispatch it in Firefox with DispatchInputEvent().

It's my first Firefox contribution. I don't know the code at all so it's hard to keep going. That's why a feedback regarding my patch (attached) is welcome. Don't hesitate to give me advices about where to continue.

Attached image wl_surface screenshot —

@panoplie, please submit your patch on phabricator, we don't do Bugzilla review
See:
https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html

Ok so I need to come back with something more acceptable if it's for an "official" review. My previous attached file was very WIP.

Someone knows where to begin to have a native Wayland backend? I struggle to cut the big task in little tasks. I feel like the transition need to be done all at once.

(In reply to panoplie from comment #12)

Ok so I need to come back with something more acceptable if it's for an "official" review. My previous attached file was very WIP.

Someone knows where to begin to have a native Wayland backend? I struggle to cut the big task in little tasks. I feel like the transition need to be done all at once.

Please note that it needs to work together with X11/GtkWindow so you'll need to keep original code path for X11 in implement a kind of switch there based on GdkIsWaylandDisplay().

You don't need to attach the patch via phabricator unless you want to integrate it to Firefox, WIP patches as bug attachments are okay.
Thanks.

Do you think it's worth create a whole new widget directory like widget/wayland or it's better to integrate the new wayland code in widget/gtk next to GTK/X11 code?

I want to mention my previous comment on the "Port Firefox to GTK4" issue here - if Gtk is never initialized in Firefox's main process when running on Wayland, and the XDG Portal interface is not available, it would be possible to initialize Gtk (potentially either Gtk3 or Gtk4) in a subprocess using IPC to handle displaying dialogs for e.g. file or color selection, or to read configuration information like light/dark mode, high contrast mode, theme colors, etc.

Out of interest: What's the use case for portal-less Wayland?
Could you just bundle or depend on a portal implementation in those situations?

I want to mention my previous comment on the "Port Firefox to GTK4" issue here - if Gtk is never initialized in Firefox's main process when running on Wayland, and the XDG Portal interface is not available, it would be possible to initialize Gtk (potentially either Gtk3 or Gtk4) in a subprocess using IPC to handle displaying dialogs for e.g. file or color selection, or to read configuration information like light/dark mode, high contrast mode, theme colors, etc.

Honestly, and especially on wayland, I would treat systems without those portals available as broken and won'tfix. This is bit like if someone went around windows and deleted a bunch of the dlls.

There might not be a "system api" to get the file chooser or what have you as the same binary may be running on either GNOME, KDE or other, but the portals are the closest we will ever get to having "cross-platform" and "platform native" apis at the same time while not making a KDE or a GNOME specific port. This issue mostly arises from thinking about "Linux™" as a monolithic target when it's very much not the case and can't ever be.

Anyway, imo you should just ignore systems that don't provide most portal that are required and error out telling them to fix their handcrafted installs.

See Also: → 1827232
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: