This is a workaround fo QTBUG-34898 and affects the VirtualBox driver
and SandyBridge Mobile. OpenGL compositing is just not possible and
crashes as soon as there is anything rendered with QtQuick. This change
should be reverted once the Qt bug is fixed.
To nevertheless use OpenGL one can as always use the KWIN_COMPOSE env
variable, though this will result in crashes. An alternative is to set
QT_OPENGL_NO_SANITY_CHECK which forces Qt into using the threaded
rendering. At least for Sandybridge this seems to be a workable solution
as it's only causing flickering in fullscreen and KWin doesn't use any
fullscreen QtQuick elements.
With QtQuick2 it's possible that the scene graph rendering context either
lives in an own thread or uses the main GUI thread. In the latter case
it's the same thread as our compositing OpenGL context lives in. This
means our basic assumption that between two rendering passes the context
stays current does not hold.
The code already ensured that before we start a rendering pass the
context is made current, but there are many more possible cases. If we
use OpenGL in areas not triggered by the rendering loop but in response
to other events the context needs to be made current. This includes the
loading and unloading of effects (some effects use OpenGL in the static
effect check, in the ctor and dtor), background loading of texture data,
lazy loading after first usage invoked by shortcut, etc. etc.
To properly handle these cases new methods are added to EffectsHandler
to make the compositing OpenGL context current. These calls delegate down
into the scene. On non-OpenGL scenes they are noop, but on OpenGL they go
into the backend and make the context current. In addition they ensure
that Qt doesn't think that it's QOpenGLContext is current by calling
doneCurrent() on the QOpenGLContext::currentContext(). This unfortunately
causes an additional call to makeCurrent with a null context, but there
is no other way to tell Qt - it doesn't notice when a different context
is made current with low level API calls. In the multi-threaded
architecture this doesn't matter as ::currentContext() returns null.
A short evaluation showed that a transition to QOpenGLContext doesn't
seem feasible. Qt only supports either GLX or EGL while KWin supports
both and when entering the transition phase for Wayland, it would become
extremely tricky if our native platform is X11, but we want a Wayland
EGL context. A future solution might be to have a "KWin-QPA plugin" which
uses either xcb or Wayland and hides everything from Qt.
The API documentation is extended to describe when the effects-framework
ensures that an OpenGL context is current. The effects are changed to
make the context current in cases where it's not guaranteed. This has
been done by looking for creation or deletion of GLTextures and Shaders.
If there are other OpenGL usages outside the rendering loop, ctor/dtor
this needs to be changed, too.
NOBODY should use org.kde.kded5 but instead directly the service
register by its own modulem, but for now let's just switch to .kded5
so we can get this running fast.
Only needs:
* Qt5::DBus for the communication with color correction
* Qt5::X11Extras for access to XCB, pulls in needed Qt5::Gui
* XCB component XCB for xcb calls in kwinglobals.h
It's basically a run of the port-cmake.sh script in here, mostly the changes
are the following:
- Using KF5::* targets
- Using the proper macros, following recent developments in frameworks
Defines the DecorationButton type in DecorationOptions (needs to be
re-defined due to QML limitations) and exports the buttons as a
QList<int> property (again QML limitations).
All QML files are switched from string to the new enum type.
A new enum is introduced which defines all the buttons known to KWin.
The defaultTitleButton methods return a list of DecorationButtons instead
of a string which needs to be parsed by the decoration. The same for the
actual title buttons. The reading/storing of the buttons is unchanged,
that is the same characters are used and mapped to the button types.
There is no difference between Oxygen and default KDecoration, so
it's not needed. It's also conceptionally wrong: decorations should
not be able to change the global default.
All the rendering to QPixmap code in the Model and the Preview is
deleted as it's no longer used.
The model still has the plugin for the border size functionality.
This probably needs a change in the API to make it completely bound
to the decoration and not a global thing.
Using a QQuickPaintedItem for the rendering. The item gets the library
name from the model and loads the decoration with its own decoration
plugin. Thus each preview has its own plugin which eliminates the need to
constantly recreate the decoration as it is done with the preview.
Having a QQuickItem gives new possibilities. The item accepts hover
events and forwards them as enter and leave events to the widgets inside
the decoration. By that the mouse interaction of e.g. Oxygen is still
functional. If the decoration uses the new update approach the bridge is
forwarding the updates to the item and triggering a repaint so we even
have animations in the preview although the widget is never shown.
A setMainWindow() method is added which behaves similar to
setMainWidget(). In addition a few convenient methods are added which
can be used by KWin core to show/hide the decoration without caring
whether the decoration uses a QWindow or QWidget.
KWin core can access the QWindow of the decoration instead of the
QWidget. This is a preparation step to allow QWidget based window
decorations without any QWidgets at all.
KWin core makes already use of this new accessor to get the window Id
which is also on QWidgets provided through the QWindow.
The PaintRedirector calls the new method KDecoration::render and passes
it's PaintDevice and the region to update to it. A decoration can
implement this method and provide an optimized implementation for the
painting which does not go through the deco's QWidget at all. In addition
the decoration can invoke an update() slot which will schedule a repaint
in the PaintRedirector and thus completely replaces the need for
intercepting paint events on the QWidget and also allows to add QWindow
based decorations in future.
Fixes incorrect button color. DecorationOptions and PlastikButton are
both connected to decoration.active and the button gets invoked first,
thus the titleBarColor is still for the previous state. This was fun!
This is a temporary solution! A proper solution needs changes in
libkdecoration and paint redirector.
The hack redirects the rendering into an FBO. After each rendering we
get a QImage from the FBO and store that in a buffer. As we unfortunately
do not know what changed, we schedule a complete update on the deco's
widget. Once we get the paint event we just render the buffer on the
widget. And thus we have copied the content to a place where it
integrates with the paint redirector.
As already written, this is a horrible hack and I'm not proud about it.
There are just too many copies involved.
So how to improve?
* deco should be able to just provide a QImage to the PaintRedirector
without the paint to the QWidget.
* only do the FBO -> QImage step if it is needed by the compositor, that
is compress the events
* for OpenGL compositing it would be totally awesome if we could just
make the contexts sharing so that we can just reuse the texture from
the FBO directly.
