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.
This reverts commit 9d4c8fda09.
Unlike other effects this wasn't using hide/show as a hack for not
having a created/destroyed signal but because the window is internally
hidden when it's in auto-hide mode despite being still mapped.
BUG: 426686
This change replaces the remaining usages of the old connect syntax with
the new connect syntax.
Unfortunately, there are still places where we have to use SIGNAL() and
SLOT() macros, for example the stuff that deals with d-bus business.
Clazy was used to create this change. There were a few cases that needed
manual intervention, the majority of those cases were about resolving
ambiguity caused by overloaded signals.
Instead of looping through the rects in the region, emit the region at
bulk. It reduces the amount of emissions we do and allows us to pack the
response accordingly.
l10n daemon script