@frandavid100 This has worked for me for years and still does.
Despite of its enormous codebase it wasn't that hard to look around and find relevant stuff - the GTK layer is fairly thin. The hardest part was to compile it, but running distcc on a Steam Deck sped it up well 😄
We still need to:
- emit pointercancel when the browser takes the touch gesture over
- not change scrolling targets during scrolling just because a new one "flew" onto the cursor/finger
- have some thresholds to differentiate between vertical and horizontal scrolling
All my #WebKit merge requests have been merged. Now #WebKitGTK supports touch PointerEvent API, touch point coordinates are fractional, synthesized mouse events are unbroken and both WebKitGTK and WPE WebKit handle pointer capture and release according to the spec. This should considerably improve compatibility of #Epiphany (#GNOME Web) with touch interfaces.
There are still some more things to fix in there, maybe someone in #mobilelinux #linuxmobile community would like to give it a try?
@datenwolf Fun fact - you can write a protocol to offload graphics operations over Wayland too, and you'll instantly get about the same adoption of it as that part of X11 has today 😁
With things like QtQuick being basically a big scene-graph canvas to draw you won't get much further than that anyway.
@datenwolf @newbyte @mirabilos @jzb The truth is - these toolkits used to work the way you describe and they have been reworked since for good reasons, which is why we can now do or think about doing things like multi-GPU with GPU hot-(un)plug, split render/display nodes, modifiers, zero-copy, desktop effects (incl. accessibility ones) and lots of other stuff that software from 90s simply did not have to concern itself with.
@datenwolf @newbyte @mirabilos @jzb So now you're saying that to reap the benefits of "old-school graphics system" you need to constrain yourself to very specific bits of software from the past? How is that different to this theoretical non-composited Wayland setup, which could actually be maintainable if anyone cared? What happened to "give the benefits to all applications, without extra effort"? 🤔
@datenwolf @newbyte @mirabilos @jzb Meanwhile in the real world even X11 clients allocate their wholly owned surfaces to be presented with DRI.
@datenwolf @newbyte @mirabilos @jzb Yes, we even had Xvideo. But you know that offloaded surfaces can be efficiently overlaid, underlaid, alpha-composited, transformed? And it works today with device-independent APIs :)
@datenwolf @newbyte @mirabilos @jzb Pretty much all of them these days, as this is handled by dmabuf feedbacks and buffer modifiers, so it works even with split render/display pipelines or with multiple GPUs.
@datenwolf @newbyte @mirabilos @jzb That's just one implementation, at least KWin and Mutter have their own ones: https://gitlab.freedesktop.org/emersion/libliftoff
GTK has GtkGraphicsOffload which is used by several apps out there - and that's just from the top of my head.
@datenwolf @newbyte @mirabilos @jzb Well, these things Just Work™ in several commonly used Wayland compositors and toolkits out there today.
@datenwolf @newbyte @mirabilos @jzb > (and lets face it, that's the only configuration in which you're hitting the display engine)
Far from it! I have some hardware next to me that won't be able to smoothly output 4K video if it goes through the GPU (and not even speaking about CPU), and yet can do it. Display pipelines in modern SoCs are a bit more complex than in 1990s.
@datenwolf @newbyte @mirabilos @jzb Modern display engines provide some in-hardware composition abilities. You're explicitly not interested in window composition, fine, but applications want to draw over buffers that are opaque to them, such as video content, which can then go straight from the VPU to the display engine without CPU or GPU involvement.
That's well-supported today with Wayland and necessary for reasonable performance on some hardware out there.
@datenwolf @newbyte @mirabilos @jzb Well, maybe because the compressed buffer is produced by the GPU and the display engine knows how to decompress it on the fly while it's fully opaque to the CPU?
@datenwolf @newbyte @mirabilos @jzb So how are you going to offload surfaces to hardware planes while preserving the ability to save memory from unused portions of the window? How are you going to utilize display's engine framebuffer compression to hit bandwidth targets on high res screens?
X11 can do lots of things, but only once you make it move away from these "old-school" ways and explode the complexity.
@datenwolf @newbyte @mirabilos @jzb I have debugged plenty of X11 and Wayland client code in my life and having to deal with "combinatorial explosion" of stuff definitely describes the experience of working with the former more than the latter.
@datenwolf @newbyte @mirabilos @jzb ...and outright don't work when presented with modern challenges, unless you're willing to put the extra effort or compromise on performance as well :)
@datenwolf @newbyte @mirabilos @jzb Buffer passing mechanics are extensible in Wayland. Even dma-bufs are in their own extension, the only one in the core is wl_shm (which, BTW, works by giving the client a buffer to mmap to...).
What's more - some toolkits, such as Qt, even have elaborate plugin support to handle custom buffer passing mechanisms that you could use.
I won't implement this for you as I'm not interested in it, but you can just sit down and do it!
@datenwolf @newbyte @mirabilos @jzb (that said, a non-composited shared-framebuffer system could be easily built on top of Wayland anyway)
@datenwolf @newbyte @mirabilos @jzb Except it's not 1980 anymore. Buffers to be presented on screen come from all sorts of sources - CPUs, GPUs, VPUs, ISPs. Some can render directly to a shared framebuffer, some can't. Some could be cropped to save memory, some can't - and when they can, they'd need to reallocate.
Yes, you can design a system that will consume less resources if you make it special-purposed to the set of requirements you happen to care about. Go ahead. Wayland is not that thing.
Hi, I'm dos. Silly FLOSS games, open smartphones, terrible music and more. 50% of @holypangolin; 100% of dosowisko.net. he/him/any. I don't receive DMs.