With the new interface, the compositor sends raw image data instead of
encoding it as a png image, which causes a lot of overhead on Wayland.
In addition to that, the new interface is more extensible, for example
we can add new options or change the written image data format, however
the latter is less likely to happen.
BUG: 433776
On Wayland, when the compositor sends a screenshot to the requesting
app, it encodes the screenshot as a PNG image and sends the encoded data
over the pipe. The requesting app (Spectacle) then needs to decode the
data.
The issue is that encoding PNG images is not cheap. This is the main
reason why Spectacle is shown with a huge delay after you press the
PrtScr key.
In order to fix the latency issue, we need to transfer raw image data.
Unfortunately, the current dbus api of the screenshot is too cluttered
and the best option at the moment is to start with a clean slate.
This change prepares the screenshot effect for versioned dbus interface.
Most of existing dbus logic was moved out in a separate class. In order
to schedule screen shots, the screenshot effect got some new API.
QFuture<QImage> scheduleScreenShot(window, flags)
QFuture<QImage> scheduleScreenShot(area, flags)
QFuture<QImage> scheduleScreenShot(screen, flags)
If a dbus interface needs to take a screenshot, it needs to call one of
the overloaded scheduleScreenShot() functions. Every overload returns a
QFuture object that can be used for querying the result.
This change also introduces "sink" and "source" objects in the dbus api
implementation to simplify handling of QFuture objects.
Note that the QFutureInterface is undocumented, so if you use it, you do
it on your own risk. However, since Qt 5.15 is frozen for non-commercial
use and some other Plasma projects already use QFutureInterface, this
is not a big concern. For what it's worth, in Qt 6, there's the QPromise
class, which is equivalent to the QFutureInterface class.
CCBUG: 433776
CCBUG: 430869
This provides the compositor a way to indicate what output is being
rendered. The effects such as the screenshot can check the provided
screen object in order to function as expected.
In QJSEngine, QRect is an Object, which is correct. This means that we
cannot use simple assignment operator to copy geometries, we need to use
standard ways to copy Objects, such as Object.assign() or the spread
operator, which is not available in QJSEngine yet.
Currently, the wobbly windows effect assumes that the window data will
be updated on every repaint. However, there are legit cases when the
time diff between frames can be 0, for example when per screen rendering
is on.
If we are unlucky enough and the geometry of the window changes in that
very short moment, the mapping between window quads and the bezier
patch will be wrong. The window will most likely bounce back and forth.
In order to improve handling of that tricky case, this change makes the
computeBezierPoint() function take the "uv" coordinates rather than the
absolute "xy" coordinates of window vertices. This loosens the
connection between the real geometry of the window and the cached bezier
patch, and overall makes the effect's timing code more robust.
This can be also useful if the wobbly windows effect starts accumulating
time diffs and performing the integration step every N msecs with the
purpose of maintaining uniform "wobbliness" across different refresh rates.
BUG: 433187
Once in a while, we receive complaints from other fellow KDE developers
about the file organization of kwin. This change addresses some of those
complaints by moving all of source code in a separate directory, src/,
thus making the project structure more traditional. Things such as tests
are kept in their own toplevel directories.
This change may wreak havoc on merge requests that add new files to kwin,
but if a patch modifies an already existing file, git should be smart
enough to figure out that the file has been relocated.
We may potentially split the src/ directory further to make navigating
the source code easier, but hopefully this is good enough already.
