https://bugs.kde.org/show_bug.cgi?id=513785
--- Comment #4 from [email protected] --- (In reply to David Edmundson from comment #3) > I agree it's important, I could close this so quickly because we have > previously discussed it all. I was not able to find anything abou this. I searched for any mention of the protocol here, on the forum, and using multiple search engines and wasn't able to finf anything. I also briefly looked for a general statement of KDEs policy regarding wayland protocols, and didn't find anything, but there i wasn't as thorough and definitely could have missed something. > Me too, but ultimately we need portals for the stuff that's not wayland > related (file open etc.) so have to do them anyway. Us supporting anything > else is increasing an ecosystem split not fixing it. I can understand that for a view limited to KDE, but as many other compositors have or are working on implementing the protocols, i don't think anything will improve. Are we cursed to forever having a split between Portals-using DEs and Protocol-using DEs? Would it not make more sense to offer both from the Compositor/DE side, to avoid application/library developers needing to implement both systems and decide which to use at runtime, which can lead to issues? (issues like this one, in a library i was considering https://github.com/nashaofu/xcap/issues/227) > This is something we are fixing both in KDE and upstream which benefits > everyone. > Out of curiosity, do you maintain one of these relevant apps? Not really, i was working on a side-project which needs rare (every few minutes) but reasonably low latency screenshots/image buffers of the display when i came across the fact that its been quite a while since the protocol was merged into wayland-protocols. As for some more on my pain points: Since i opened this i switched from using a screencapture library to rolling it myself using a portals library and pipewire bindings, which led me to lern about session restore tokensz which alleviate the "constant popups" pain point. The main functionality pain-point (besides the surrounding ones like being forced to depend on pipewire) is the lack of a way to take screenshots to memory/fd/drm-buf. The screenshot portal always saves to a file on disk, which is nice if thats what you want, but horrible for latency when you need to do anything to the screenshot beyond saving it. To solve this in my application, i start a full screencast through pipewire which has a callback that puts the raw frame data into a channel to send it to a thread which only exists overwrite the last stored frame with the new one. This is quite a hassle and a giant waste of CPU cycles just to be able to get a reasonably up-to-date frame with low latency. Heres the project, if you care: https://github.com/laundmo/wf_overlay/ But i think i've talked in a closed issue for long enough, and will at some point take the time to write a new one about the screenshot API lacking support for *not* writing to disk. I'm frustrated sith KDEs decision on this, but at this point it seems pretty set in stone. -- You are receiving this mail because: You are watching all bug changes.
