The Renderer gets reparented to the Deleted. While passing it to
the Deleted the Scene's implementation can ensure that the buffers
are up to date. After passing to Deleted it's no longer allowed to
call the render method.
NOTE: this is not working completely yet, lots of code is still ifdefed
other parts are still broken.
The main difference for the new decoration API is that it is neither
QWidget nor QWindow based. It's just a QObject which processes input
events and has a paint method to render the decoration. This means all
the workarounds for the QWidget interception are removed. Also the paint
redirector is removed. Instead each compositor has now its own renderer
which can be optimized for the specific case. E.g. the OpenGL compositor
renders to a scratch image which gets copied into the combined texture,
the XRender compositor copies into the XPixmaps.
Input events are also changed. The events are composed into QMouseEvents
and passed through the decoration, which might accept them. If they are
not accpted we assume that it's a press on the decoration area allowing
us to resize/move the window. Input events are not completely working
yet, e.g. wheel events are not yet processed and double click on deco
is not yet working.
Overall KDecoration2 is way more stateful and KWin core needs more
adjustments for it. E.g. borders are allowed to be disabled at any time.
The left and right border images are rotated 90° before they are
uploaded into the atlas texture. The images are separated by a row
of transparent texels to minimize artifacts from oversampling.
With this change kwin renders the whole decoration with a single
call to glDrawArrays().
When this property is true, it indicates that the +U axis corresponds
to the +Y axis, and the +V axis corresponds to the +X axis.
This property is taken into account in WindowQuad::makeSubQuad().
It doesn't make sense to convert the extension names to QStrings.
This also replaces the QString parameter in hasGLExtension() with
a QByteArray and adjusts all callers.
Remove the manually written GL dispatch code, and use libepoxy
to resolve functions.
The only exceptions are GLX_MESA_swap_control, which is not in
the XML API registry, and GL_ARB_robustness/GL_EXT_robustness.
For the latter we want to resolve the functions to the same names
on both GLES and desktop GL, and plug in our own implementations
when the extension is not supported.
and copy isSpecialWindow() check as rulebook input
to setFullscreen()
Client::isFullScreenable() checks:
* fullscreen rule
* fullscreen_hack (-> for normal windows)
* geometry restrictions
* special window
Client::manage() for fullscreeining checks:
* fullscreen rule (with correct "initial" parameter)
* fullscreen_hack
-> this breaks the fullscreen rule for geometry restricted windows
and causes inconsistent behavior between client requests at runtime
(which do not test ::isFullScreenable()) and on mapping.
Otoh, the specialWindow() protection should apply generally - those
kind of windows should not be fullscreened since the user can not
exit this state via kwin for them - and there's hardly a good reason
for them to be fullscreen, esp. not to enter that state at runtime
REVIEW: 118442
CCBUG: 335617
Cherry-picked from kde-workspace
43229afee9fac4303e3d280ea63f96f034b3ffb5
It's possible that the rendering thread is still writing to the
buffer and if we destroy the buffer before it's finished KWin is going
to crash. So let's mutex lock the dtor to ensure that the rendering
thread finishes before we tear down the client.
BUG: 336950
Seems like porting to new infrastructure was incomplete. The
MaximizeRestore button consists of two buttons on top of each other with
an own mouse area in each and both always visible. This means the restore
button was stealing the mouse events of the maximize button breaking
maximization.
The solution is to have an additional MouseArea which controls the whole
button making the two button types just visualization.
This is going to be a controversal change. It enforces KWin decorations
on all client side decorated windows from GTK+. Unfortunately we are
caught between a rock and a hard place. Keeping the status quo means
having broken windows and a more or less broken window manager due to
GTK+ including the shadow in the windows. This is no solution.
Enforcing server side decorations visually breaks the windows. This is
also no solution. So why do it?
It's our task to provide the best possible user experience and KWin is
a window manager which has always done great efforts to fix misbehaving
windows. One can think of the focus stealing prevention, the window rules
and lately the scripts. The best possible window management experience is
our aim. This means we cannot leave the users with the broken windows
from GTK.
The issues we noticed were reported to GTK+ about 2 months ago and we are
working on improving the situation. Unfortunately several issues are not
yet addressed and others will only be addressed in the next GTK+ release.
We are working on improving the NETWM spec (see [1]) to ensure that the
client side decorated windows are not in a broken state. This means the
enforcment is a temporary solution and will be re-evaluated with the next
GTK release. I would prefer to not have to do such a change, if some of
the bugs were fixed or GTK+ would not use client-side-decos on wms not
yet supporting those all of this would be a no issue.
For a complete list of the problems caused by GTK's decos see bug [2] and
the linked bug reports from there.
The change is done in a least inversive way in KWin. We just check for
the property _GTK_FRAME_EXTENTS and create a Q_PROPERTY in Client for it.
If we add support for the frame extents in future we would also need
this. So it's not a change just for enforcing the decoration.
The actual enforcing is done through a KWin script so users can still
disable it.
REVIEW: 119062
[1] https://mail.gnome.org/archives/wm-spec-list/2014-June/msg00002.html
[2] https://bugzilla.gnome.org/show_bug.cgi?id=729721
This reverts commit c09d63d192.
The test results we got indicate that on NVIDIA the problems with the
threaded rendering loop do not exist and at the same time the rendering
result improves a lot. As Qt still disables the threaded rendering loop
for the problematic drivers, it's better to not force the basic rendering
loop.
