yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/effects/backgroundcontrast/contrast.h

92 lines
2.8 KiB
C
Raw Normal View History

stub for the background contrast effect * a copy of the blur shader to become a copy of the background contrast effect * contrastshader actually doing the light modification * don't expand/shrink the area
2013-12-01 19:28:57 +00:00
/*
Prettify license headers
2020-08-02 22:22:19 +00:00
SPDX-FileCopyrightText: 2010 Fredrik Höglund <fredrik@kde.org>
SPDX-FileCopyrightText: 2014 Marco Martin <mart@kde.org>
SPDX-License-Identifier: GPL-2.0-or-later
*/
stub for the background contrast effect * a copy of the blur shader to become a copy of the background contrast effect * contrastshader actually doing the light modification * don't expand/shrink the area
2013-12-01 19:28:57 +00:00
#ifndef CONTRAST_H
#define CONTRAST_H
#include <kwineffects.h>
#include <kwinglplatform.h>
#include <kwinglutils.h>
#include <QVector>
#include <QVector2D>
Port KWin to KWaylandServer Summary: Away from KWayland::Server and KF5WaylandServer. Test Plan: Builds, ran nested session Reviewers: #kwin, #plasma, #frameworks, davidedmundson, zzag Reviewed By: #kwin, #plasma, davidedmundson, zzag Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D29278
2020-04-29 15:18:41 +00:00
namespace KWaylandServer
[effects] Properly announce/remove support in blur/contrast if shader fails Following the approach how it's done for X11: only create the interface if the shader succeeded to compile and remove support again if it failed to compile after a reconfigure. REVIEW: 125444
2015-09-29 08:21:24 +00:00
{
class ContrastManagerInterface;
}
stub for the background contrast effect * a copy of the blur shader to become a copy of the background contrast effect * contrastshader actually doing the light modification * don't expand/shrink the area
2013-12-01 19:28:57 +00:00
namespace KWin
{
class ContrastShader;
class ContrastEffect : public KWin::Effect
{
Q_OBJECT
public:
ContrastEffect();
[effects/backgroundcontrast] Use override keyword Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16262
2018-10-16 21:51:44 +00:00
~ContrastEffect() override;
stub for the background contrast effect * a copy of the blur shader to become a copy of the background contrast effect * contrastshader actually doing the light modification * don't expand/shrink the area
2013-12-01 19:28:57 +00:00
static bool supported();
static bool enabledByDefault();
reintroduce prepaintscreen * work also without blur enabled * try to pass only the 3 color parameters
2014-01-06 20:43:03 +00:00
static QMatrix4x4 colorMatrix(qreal contrast, qreal intensity, qreal saturation);
[effects/backgroundcontrast] Use override keyword Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16262
2018-10-16 21:51:44 +00:00
void reconfigure(ReconfigureFlags flags) override;
Provide expected presentation time to effects 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.
2020-11-20 15:44:04 +00:00
void prePaintScreen(ScreenPrePaintData &data, std::chrono::milliseconds presentTime) override;
void prePaintWindow(EffectWindow *w, WindowPrePaintData &data, std::chrono::milliseconds presentTime) override;
Add some const & Summary: Won't make things go much faster since everything that was being passed by value is refcounted but still const & is a bit faster than refcounting For shared pointers instead of adding const & we move them into the destination variable saving some cpu usage but at the same time making clear the pointer is being stored by not being const & Reviewers: zzag Reviewed By: zzag Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D25022
2019-10-29 22:04:15 +00:00
void drawWindow(EffectWindow *w, int mask, const QRegion &region, WindowPaintData &data) override;
void paintEffectFrame(EffectFrame *frame, const QRegion &region, double opacity, double frameOpacity) override;
stub for the background contrast effect * a copy of the blur shader to become a copy of the background contrast effect * contrastshader actually doing the light modification * don't expand/shrink the area
2013-12-01 19:28:57 +00:00
[effects/backgroundcontrast] Use override keyword Test Plan: Compiles. Reviewers: #kwin, davidedmundson Reviewed By: #kwin, davidedmundson Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D16262
2018-10-16 21:51:44 +00:00
bool provides(Feature feature) override;
effects: Disable blur and contrast effect when screen is locked The results of the blur and the background contrast effect will never be seen if the screen locker is active. In order to avoid wasting computational resources, we could temporarily disable the blur effect until the screen is unlocked. Furthermore, given that the blur effect shrinks the clip region, it is guaranteed that the compositor will have to render the desktop window behind the lockscreen window. With this change, all windows behind the screen locker will be properly clipped away.
2020-08-31 18:11:06 +00:00
bool isActive() const override;
stub for the background contrast effect * a copy of the blur shader to become a copy of the background contrast effect * contrastshader actually doing the light modification * don't expand/shrink the area
2013-12-01 19:28:57 +00:00
[kwin] Add a virtual Effect::requestedEffectChainPosition This method replaces the X-KDE-ORDERING property in the Effect's desktop files. This change is a preparation step for integrating the new Effect Loader which doesn't read the ordering information. Thus it needs to be provided by the Effect itself so that the EffectsHandler can properly insert it into the chain. Also for the built-in Effects on the long run it doesn't make much sense to install the desktop files. And binary plugin effects will migrate to json metadata which also doesn't have the KService::Ptr. Thus overall it simplifies to read this information directly from the Effect.
2014-03-24 10:50:09 +00:00
int requestedEffectChainPosition() const override {
return 76;
}
Add windowsystem plugin for KWin's qpa Summary: KWindowSystem provides a plugin interface to have platform specific implementations. So far KWin relied on the implementation in KWayland-integration repository. This is something I find unsuited, for the following reasons: * any test in KWin for functionality set through the plugin would fail * it's not clear what's going on where * in worst case some code could deadlock * KWin shouldn't use KWindowSystem and only a small subset is allowed to be used The last point needs some further explanation. KWin internally does not and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is exposing information which KWin sets. It's more than weird if KWin asks KWindowSystem for the state of a window it set itself. On X11 it's just slow, on Wayland it can result in roundtrips to KWin itself which is dangerous. But due to using Plasma components we have a few areas where we use KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in direction, blur and background contrast. This we want to support and need to support. Other API elements we do not want, like for examples the available windows. KWin internal windows either have direct access to KWin or a scripting interface exposed providing (limited) access - there is just no need to have this in KWindowSystem. To make it more clear what KWin supports as API of KWindowSystem for internal windows this change implements a stripped down version of the kwayland-integration plugin. The main difference is that it does not use KWayland at all, but a QWindow internal side channel. To support this EffectWindow provides an accessor for internalWindow and the three already mentioned effects are adjusted to read from the internal QWindow and it's dynamic properties. This change is a first step for a further refactoring. I plan to split the internal window out of ShellClient into a dedicated class. I think there are nowadays too many special cases. If it moves out there is the question whether we really want to use Wayland for the internal windows or whether this is just historic ballast (after all we used to use qwayland for that in the beginning). As the change could introduce regressions I'm targetting 5.16. Test Plan: new test case for window type, manual testing using Alt+Tab for the effects integration. Sliding popups, blur and contrast worked fine. Reviewers: #kwin Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D18228
2019-01-13 16:50:32 +00:00
bool eventFilter(QObject *watched, QEvent *event) override;
stub for the background contrast effect * a copy of the blur shader to become a copy of the background contrast effect * contrastshader actually doing the light modification * don't expand/shrink the area
2013-12-01 19:28:57 +00:00
public Q_SLOTS:
void slotWindowAdded(KWin::EffectWindow *w);
support the kwayland contrast protocol support wayland as well in the background contrast effect REVIEW:125035
2015-09-03 15:00:24 +00:00
void slotWindowDeleted(KWin::EffectWindow *w);
reintroduce prepaintscreen * work also without blur enabled * try to pass only the 3 color parameters
2014-01-06 20:43:03 +00:00
void slotPropertyNotify(KWin::EffectWindow *w, long atom);
stub for the background contrast effect * a copy of the blur shader to become a copy of the background contrast effect * contrastshader actually doing the light modification * don't expand/shrink the area
2013-12-01 19:28:57 +00:00
void slotScreenGeometryChanged();
private:
QRegion contrastRegion(const EffectWindow *w) const;
bool shouldContrast(const EffectWindow *w, int mask, const WindowPaintData &data) const;
store contrast matrix per-window Summary: as different windows can have different contrast region parameters, store color matrices per window BUG:339237 Test Plan: logout window doesn't break panel anymore Reviewers: #plasma, graesslin Reviewed By: #plasma, graesslin Subscribers: broulik, plasma-devel, kwin, #kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D5048
2017-03-15 11:02:22 +00:00
void updateContrastRegion(EffectWindow *w);
void doContrast(EffectWindow *w, const QRegion &shape, const QRect &screen, const float opacity, const QMatrix4x4 &screenProjection);
stub for the background contrast effect * a copy of the blur shader to become a copy of the background contrast effect * contrastshader actually doing the light modification * don't expand/shrink the area
2013-12-01 19:28:57 +00:00
void uploadRegion(QVector2D *&map, const QRegion &region);
one single pass, get rid of cached version * this effect is way cheaper than blur, don't cache it * use its own atom * also pass the matrix in the x property * remove remnants of the cache * do just a single pass * get rid of config ui remnants
2013-12-03 19:20:45 +00:00
void uploadGeometry(GLVertexBuffer *vbo, const QRegion &region);
stub for the background contrast effect * a copy of the blur shader to become a copy of the background contrast effect * contrastshader actually doing the light modification * don't expand/shrink the area
2013-12-01 19:28:57 +00:00
private:
ContrastShader *shader;
one single pass, get rid of cached version * this effect is way cheaper than blur, don't cache it * use its own atom * also pass the matrix in the x property * remove remnants of the cache * do just a single pass * get rid of config ui remnants
2013-12-03 19:20:45 +00:00
long net_wm_contrast_region;
reintroduce prepaintscreen * work also without blur enabled * try to pass only the 3 color parameters
2014-01-06 20:43:03 +00:00
QRegion m_paintedArea; // actually painted area which is greater than m_damagedArea
QRegion m_currentContrast; // keeps track of the currently contrasted area of non-caching windows(from bottom to top)
store contrast matrix per-window Summary: as different windows can have different contrast region parameters, store color matrices per window BUG:339237 Test Plan: logout window doesn't break panel anymore Reviewers: #plasma, graesslin Reviewed By: #plasma, graesslin Subscribers: broulik, plasma-devel, kwin, #kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D5048
2017-03-15 11:02:22 +00:00
QHash< const EffectWindow*, QMatrix4x4> m_colorMatrices;
support the kwayland contrast protocol support wayland as well in the background contrast effect REVIEW:125035
2015-09-03 15:00:24 +00:00
QHash< const EffectWindow*, QMetaObject::Connection > m_contrastChangedConnections; // used only in Wayland to keep track of effect changed
Port KWin to KWaylandServer Summary: Away from KWayland::Server and KF5WaylandServer. Test Plan: Builds, ran nested session Reviewers: #kwin, #plasma, #frameworks, davidedmundson, zzag Reviewed By: #kwin, #plasma, davidedmundson, zzag Subscribers: zzag, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D29278
2020-04-29 15:18:41 +00:00
KWaylandServer::ContrastManagerInterface *m_contrastManager = nullptr;
stub for the background contrast effect * a copy of the blur shader to become a copy of the background contrast effect * contrastshader actually doing the light modification * don't expand/shrink the area
2013-12-01 19:28:57 +00:00
};
inline
bool ContrastEffect::provides(Effect::Feature feature)
{
one single pass, get rid of cached version * this effect is way cheaper than blur, don't cache it * use its own atom * also pass the matrix in the x property * remove remnants of the cache * do just a single pass * get rid of config ui remnants
2013-12-03 19:20:45 +00:00
if (feature == Contrast) {
stub for the background contrast effect * a copy of the blur shader to become a copy of the background contrast effect * contrastshader actually doing the light modification * don't expand/shrink the area
2013-12-01 19:28:57 +00:00
return true;
}
return KWin::Effect::provides(feature);
}
} // namespace KWin
#endif
Reference in a new issue Copy permalink