On Wayland, the highlight window effect is not guaranteed to work all
the time because it uses the opacity to determine if the animation has
completed.
This change rewrites the highlight window effect using AnimationEffect
API to make it work both on X11 and Wayland. The implementation is based
on how the translucency effect works.
Warning messages are not the kind of messages that should be ignored,
they indicate that something is off or wrong.
Also, this makes triaging bugs easier as we no longer have to ask people
to run kwin with the QT_LOGGING_RULES environment variable set.
QMap::value() failed to find existing keys when tow ComparablePoint
shared the same x but not the same y.
This commit improves the operator<() to fix that.
Effects are given the interval between two consecutive frames. The main
flaw of this approach is that if the Compositor transitions from the idle
state to "active" state, i.e. when there is something to repaint,
effects may see a very large interval between the last painted frame and
the current. In order to address this issue, the Scene invalidates the
timer that is used to measure time between consecutive frames before the
Compositor is about to become idle.
While this works perfectly fine with Xinerama-style rendering, with per
screen rendering, determining whether the compositor is about to idle is
rather a tedious task mostly because a single output can't be used for
the test.
Furthermore, since the Compositor schedules pointless repaints just to
ensure that it's idle, it might take several attempts to figure out
whether the scene timer must be invalidated if you use (true) per screen
rendering.
Ideally, all effects should use a timeline helper that is aware of the
underlying render loop and its timings. However, this option is off the
table because it will involve a lot of work to implement it.
Alternative and much simpler option is to pass the expected presentation
time to effects rather than time between consecutive frames. This means
that effects are responsible for determining how much animation timelines
have to be advanced. Typically, an effect would have to store the
presentation timestamp provided in either prePaint{Screen,Window} and
use it in the subsequent prePaint{Screen,Window} call to estimate the
amount of time passed between the next and the last frames.
Unfortunately, this is an API incompatible change. However, it shouldn't
take a lot of work to port third-party binary effects, which don't use the
AnimationEffect class, to the new API. On the bright side, we no longer
need to be concerned about the Compositor getting idle.
We do still try to determine whether the Compositor is about to idle,
primarily, because the OpenGL render backend swaps buffers on present,
but that will change with the ongoing compositing timing rework.
if the dock is on the top,and the dock is not close together with screen edge.
for example,the dock is 10 pixels taller then sceen edge,the "position" will be "Bottom".
Autually,the dock is on the top of screen.
Add a new field to EffectData that stores an effect's config module.
We currently determine an effect's configModule using KPluginTrader and the X-KDE-ParentComponents metadata.
IMO it's much more straight forward to let the effect specify its config module directly instead.
Since commit commits.kde.org/plasma-workspace/378309e666f52fc436c75648a9e6ad7d5dcbacdf
ksmserver sets a desktopname when restoring applications. This causes the effect
to draw above the splash windows while no cursor is visible.
We want to multiply the width/height by scale weather or not we are
using GLES or not, otherwise this will only provide part of screen when
used with e.g fullscreen screenshot.
The following click behaviors are defined:
* Switch desktop and activate window [default]
* Switch desktop only
The former emulates the previous default of activating clicked windows
using the Present Windows effect. The latter introduces a new mode where
the clicked window is not activated, allowing the user to select a
virtual desktop without worrying about disrupting the last active
window.
The configuration toggle that controlled the use of the Present Windows
effect has been subsumed into the first click behavior, i.e., if the
effect is enabled, it will be implicitly triggered.
