https://bugs.kde.org/show_bug.cgi?id=523971
--- Comment #5 from Noah Davis <[email protected]> --- (In reply to Ellie from comment #3) > Isn't kwin the component that "owns" the input and output? I'm asking > because if kwin originally gets the print request via the key press it self, > I'm slightly surprised there is a dbus roundtrip involved at all. (I get > that for launching spectacle and the UI and all that there might be, but I > would assume ideally kwin doesn't wait for that to take the screenshot.) I'm not an expert on Wayland or even KWin in particular, so take the first part of this explanation with a grain of salt. I do have some experience with the inner workings of KWin's screenshot plugin. 1. As the compositor, KWin might detect keyboard input that happens to have PrintScreen. 2. KWin might not know what PrintScreen is supposed to do, but the global shortcut handling service would. In one way or another, it passes the input to the global shortcut service. PrintScreen does not necessarily launch Spectacle. It could do something else depending on the system configuration. 3. In our case, the global shortcut action that uses PrintScreen launches Spectacle, so Spectacle is launched. 4. If configured to take a screenshot on launch (a default setting), Spectacle asks KWin for screenshots via DBus. On some level, this architecture might seem wasteful, but the steps above typically aren't slow enough that the problem is with them. It is actually helpful for designing a robust and configurable system to have things separated this way. If everything was as fully integrated as possible, an error in Spectacle or the global shortcuts service could bring down KWin. Since KWin is the root of the whole session on Wayland, this could cause data loss if there are apps with unsaved data. Qt apps have a certain degree of integration for automatic restoration, but I'm not sure if all Qt apps are integrated or the degree to which they can be restored. It also might be difficult to allow screenshot apps besides Spectacle to be used if the system was not designed this way. It is more likely that the delay happens either in the part that receives screenshot requests and sends image data (KWin) or in the part that sends screenshot requests and receives image data (Spectacle). Once Spectacle receives a reply from KWin, the moment in time can be considered captured, regardless of how long it takes Spectacle to fully process the image data and show the images to the user. That is why in my previous comment I said that the time to read the data is not so important. It is important for the overall user experience, but not for the issue of screen capture latency. -- You are receiving this mail because: You are watching all bug changes.
