Here's some rough ideas for actionable improvements that I see being useful when it comes to graphical framework fixes to grayjay, listed with the most feasible ones first:
0. Identify solutions to the issues mentioned that could be patched in the flatpak
If anyone digs into the issues listed in the original issue description enough to be able to demonstrate a particular patch that solves the issue and can be applied to the grayjay flatpak distribution, I would be happy to take a look at it and merge it until it is able to be upstreamed for all Grayjay users.
1. Upgrade dotcefnative from GTK3 to GTK4
upgrading dotcefnative (i.e. the source code in the native directory of the JustCef repo, which is essentially a CEF/chromium embedded wrapper) from GTK3 to GTK4. This essentially means getting things to the point that the --use-native flag (which is one of the custom things added by the dotcefnative wrapper) is able to support linux desktop environments.
Benefits: This would bring in potentially automatic wayland support (GTK4 supports X11 and wayland) which is something that currently impacts a lot of Grayjay linux users. This would also give FUTO more control over how things are rendered by creating our own GTK window and displaying the chromium/CEF instance inside of it, potentially removing or helping mitigate issues while we wait for CEF to get the same kind of Wayland support that chromium has had for a little while now.
This is the only option I currently see as having a realistic chance of getting merged.
2. Contribute to CEF to improve their support for the various issues that Grayjay is facing
Somewhat self-explanatory, but one possible solution is to join the various efforts to help fix these kinds of rendering issues in CEF itself.
The big downside for this is that chromium and CEF are huge projects and things are probably going to be quite complicated and slow-moving, but at least the effort will benefit all other desktop apps that use CEF (such as steam and spotify)
3. experiment with swapping out CEF for Electron
Swapping out CEF for electron as the framework that runs Grayjay desktop would essentially mean moving to a more widely-used framework, which, to my knowledge, already supports a lot of things like wayland, taskbar grouping, etc that are current issues (in other words, i imagine many electron apps have already solved a lot of the issues mentioned in the original issue). Another benefit is that electron is available as a flatpak baseapp, which makes it easier to build, distribute, and update electron apps on flatpak compared to CEF based ones.
This, however, is likely to be harder than option 1 above because dotcefnative is tightly integrated with libcef, and based on a minimal amount of research, it seems like Electron chose to ditch CEF early on and do things a different way. This is also quite likely to involve bringing in more javascript (which may go against the stated goal of OP) since I suspect that electron relies on JS as its interface with chromium, much like how libcef uses a traditional C-style API/interface.
This option is more of an experiment in that, while its maybe technically easier to get started with, I don't see it being wholesale switched to for all of Grayjay desktop without a whole lot of back and forth to make sure that it still works for all the same things that CEF is currently being used for and that electron it is a solution that is able to be supported in the long term.
4. experiment with another web based framework
Same as above but with some other framework for packaging apps written in web technologies as desktop apps. its lower on the list because Im currently unaware of any such frameworks and thus the implementation effort is likely to be higher.
5. Adapt other FOSS video tools to be compatible with grayjay features Assuming the maintainers of other video apps are on board, adding your favorite grayjay features into other FOSS video player apps (maybe something like sync, or the plugin system, or the "cast to" feature) may help bring these other apps close enough to Grayjay feature-wise that they may be with switching to for people who don't use very many Grayjay features to being with and for whom the graphical/rendering issues are incredibly annoying. Plus, this could help bring more people into the Grayjay ecosystem, or even help all media players stay more up to date on changes youtube and other platforms are making through collaborating (especially if several apps utilize the same plugin system).
Yes this idea is a lot of work. I wouldnt recommend it, but its at least less work than any of the below options
6. Start your own media aggregator Starting your own brand new third-party media aggregator app would allow the creator complete freedom to choose the framework being used. If made compatible with the Grayjay plugin system, sync, etc, you could potentially get somewhat close to feature parity, but there would still be a LOT of integration work and compliance checking to ensure that things are done in a way that doesnt cause technical or legal issues.
7. Wholesale rewrite of the Grayjay UI
I placed this after writing a brand new app because, not only will you have most of the effort of starting over, but you will also be more constrained as you do so, since there will be additional considerations such as: fitting in with the exsting Grayjay feature development cycle, communicating with the existing team to ensure they are happy with the way things are built (as theyll be the ones responsible for its maintainance), etc.