As all effects have always been compiled into the same .so file it's
questionable whether resolving the effects through a library is useful
at all. By linking against the built-in effects we gain the following
advantages:
* don't have to load/unload the KLibrary
* don't have to resolve the create, supported and enabled functions
* no version check required
* no dependency resolving (effects don't use it)
* remove the KWIN_EFFECT macros from the effects
All the effects are now registered in an effects_builtins file which
maps the name to a factory method and supported or enabled by default
methods.
During loading the effects we first check whether there is a built-in
effect by the given name and make a shortcut to create it through that.
If that's not possible the normal plugin loading is used.
Completely unscientific testing [1] showed an improvement of almost 10
msec during loading all the effects I use.
[1] QElapsedTimer around the loading code, start kwin five times, take
average.
REVIEW: 115073
This compositor uses only the QPainter API to perform rendering. The
window's X Pixmap is mapped to a QImage using XShm. As rendering backend
a QImage is used.
The new compositing type "QPainterCompositing" is introduced. Effects
need to be adjusted to explicitly check the compositing type and no
longer assume the compositing type is XRender if it's not OpenGL.
This compositor can be selected with using "Q" as the value for
KWIN_COMPOSE env variable or setting the config value to "QPainter".
The GUI is not yet adjusted to select this compositor.
The QPainter scene provides currently the following features:
* 2D transformations (translation and scalation)
* opacity modifications
* rendering of decorations (new PaintRedirector sub class)
* rendering of shadows
* rendering of effect frames
* rendering to a Wayland surface
The following features are currently not provided:
* saturation changes
* brightness changes
* 3D transformations
* rendering to X Overlay window
* offscreen rendering (e.g. needed for screen shot effect)
* custom rendering in the effects to the current back buffer
The functionality to create the connection to a Wayland compositor and
creating a fullscreen surface is moved into wayland_backend.(h|cpp). The
wl_egl_window for the surface is moved into the EglWaylandBackend to have
the actual WaylandBackend free from Egl. This will allow in future to
implement other compositing backends for Wayland which do not use egl.
This means that egl is no longer a build requirement for the wayland
related functionality.
By not using a QQuickView it becomes possible to just use a
PlasmaCore.Dialog or a Quick.Window in the TabBox qml and thus it's
possible to simplify the qml code.
To support this a new SwitcherItem is introduced and exported to QML.
It's a simple QObject providing all the properties which used to be
exported to the root context. A declarative TabBox is expected to
use one of these items. The C++ side finds the Switcher and for that
supports the case that the SwitcherItem is the rootItem or a child
item.
A declarative TabBox has also to create a QQuickWindow, e.g. a
PlasmaCore.Dialog. The visibility of that window should be controlled
through the visible property on the SwitcherItem. The underlying C++
implementation assumes that a TabBox only uses one window (it needs to
get destroyed once it's hidden and included in highlight windows).
Thanks to this change it's no longer needed to reload the TabBox
whenever it gets shown or the alternative TabBox gets shown. Instead
the same QML script can get reused. Other created switchers are ignored
as the visible property won't be changed to true.
Instead we generate an export header for kdeinit_kwin and use it
to declare the KWIN_EXPORT. With this change our libs don't include
any KDE4Support headers any more. One step closer to no KDE4Support.
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
The xcb sync protocol is incorrectly defined (see [1]) which results in
xcb_sync_create_alarm not creating a valid alarm. To work around this
issue we only create the alarm without setting the int64 values. For
those we use the XLib XSyncChangeAlarm call after we verified that the
alarm got created. This unfortunately reintroduces linking against
libxext. But at least resizing works again.
[1] http://lists.freedesktop.org/archives/xcb/2013-June/008375.html
The main purpose of the opengl testapp was to set the environment
variable LIBGL_ALWAYS_INDIRECT if direct rendering is not supported
before glx gets initialized.
With Qt5 we may no longer set this environment variable. QtQuick
requires direct rendering. On IvyBridge QtQuick is crashing if the
variable is set. Thus we are no longer allowed to set it and thus the
complete test becomes pointless.
The test app basically whitelisted most drivers anyway, the only
drivers which were problematic are the proprietary Catalyst drivers.
It that's still a problem we can also disable OpenGL compositing on
those drivers through the recommendation in the GLPlatform.
This also means that the KWIN_DIRECT_GL variable is no longer useful.
As KWin indirectly uses Qt's OpenGL through QtQuick we need to ensure
to not mix OpenGL and OpenGLES. So we have to built KWin only against
OpenGL if Qt is built against OpenGL and we have to built KWin only
against GLESv2 if Qt is built against GLESv2.
This means the kwin_gles binary is no more. There is only kwin which
either links GL or GLESv2.
Note to people compiling from source: it's only the default of the
cmake variable which got changed. You have to delete the variable
from the cache to get this change.
The DBusCall is exported as a QObject to the QML environment. It is
intended as a declarative replacement for the callDBus method which used
to be exported on global scope in the QtQuick 1 world.
Example usage:
DBusCall {
id: dbus
service: "org.kde.KWin"
path: "/KWin"
method: "setCurrentDesktop"
arguments: [1]
Component.onCompleted: dbus.call()
}
Getting all functionality from old solution into new one is not really
possible. Main problems are that QtScript provided more functionality
than the QJSEngine. For example it's no longer possible to just export
functions to the engine. We need to have a Qt wrapper object. At the
moment this wrapper object doesn't export all functions as the callbacks
are tricky. A solution might be to create specific QML types
encapsulating functionality which used to be exported on the functions.
Nevertheless a basic QML script loads and works and the ported readConfig
function works, too.
AbstractThumbnailItem inherits from QQuickPaintedItem using QPainter to
do the fallback painting of icons.
The scene is adjusted to get the information from QQuickItem instead of
QDeclarativeItem. Clipping got a little bit more complex as the clip
path does not exist any more. To get it right the ThumbnailItem needs to
specify the parent it wants to be clipped to with the clipTo property.
E.g.:
clipTo: listView
The scene uses this clipTo parent item to correctly calculate the clip
region. Also the ThumbnailItem needs to have clipping enabled.
Note: this commit currently breaks TabBox as the qml and view are not
yet adjusted. In scripting the export of the item is disabled, but any
qml script using a ThumbnailItem would obviously also fail.
1. it apparently is ineffective
2. if it was effective, it's current behavior would be not exactly helpful
(sets __GL_YIELD to NOTHING, causing busy waits on doublebuffer swapping)
3. it does for sure pollute the doublebuffer/usleep detection (setenv is set to override),
ie. the overehad detection code gets a different opinion on __GL_YIELD than libGL
REVIEW: 111858
CCBUG: 322060
To ease porting a few features are disabled, this includes:
* kcms
* decorations
* activities
Note: KWin doesn't work yet, the event filter is not yet ported!
Martin Gräßlin