I frankly doubt this will fix unless we abandon the QtQuick outline window in the composited case.

What could be possible to mitigate the problem would be to delay ::setElectricBorderMaximizing() ie. set a state and bump a 250ms timer (so that the showing will simply not occur on rather fast movements)

what might improve is getting a shared QQmlEngine for our stuff, so that it's not recreated on each show.

void CompositedOutlineVisual::show()
{
    if (m_qmlContext.isNull()) {
        m_qmlContext.reset(new QQmlContext(Scripting::self()->qmlEngine()));
        m_qmlContext->setContextProperty(QStringLiteral("outline"), outline());
    }


Looks like
a) the engine is shared
b) it's only recreated on compositing chages at best anyway

I had assumed the problem was with actually mapping the QtQuick GL context (maybe QtQuick internally deletes the context and recreates it on mapping only)

oh right, it's already shared.

What might be more a problem are:

void CompositedOutlineVisual::hide()
{
    if (QQuickWindow *w = qobject_cast<QQuickWindow*>(m_mainItem.data())) {
        w->hide();
        w->destroy();
    }
}

Which basically causes the window to be destroyed on each hide. I remember to have added that because of issues with the free driver stack (totally didn't update). Maybe that's not an issue with nvidia and we can make that a driver specific check. I'll also try whether this is needed at all nowadays.

> I'll also try whether this is needed at all nowadays.

oh yes, that's still needed at least on Intel.

Just as well on nvidia  - the problem is rather in QtQuick than in the driver stack (mind eg. the artifacts on the +/- desktop grid buttons)

We could go for that silly hide-is-move approach from the effect buttons, but in this case I assume just blending away invocation is the more elegant <s>solution</s> workaround.


However, tbh. atm. I'm personally in favor to remove all QtQuick bits of this kind for it's apparently neither designed nor suited for this kind of short-term invocation.

Eg. the effect buttons could be unstyled effect frames (since we grab input anyway) what costs nothing - and a translucent unstyled effect frame would actually not make any visual difference from the outline appearance of the "breeze dark" theme :-P

Not sure about the tabbox, though. We could use scripting to position box and icons/labels/thumbnails, but QtScript is deprecated and I/we don't know yet how much portable client code will be reg. QJSEngine.

well moving away from QtQuick means that we make theming more difficult. One of the thoughts I had in mind with QtQuick was making it easy for e.g. LXQt to use KWin without having to depend on Plasma's visuals.

On Wayland btw. the whole thing looks much better which makes me think it might also be related to the way Qt uses xcb - especially if one considers stuff like https://git.reviewboard.kde.org/r/124948/

oh and something to also look into: share context. On Wayland it's super awesome as we can share the context with the compositor and just render into a FBO and use that as the window texture. If we could get that to work for X11 as well, we might get rid of all the problems as we just bypass the async XCB.

But I so far failed to make the context sharing and especially it cannot work if one is GLX and the other EGL (or the other way around).

Neither on xrender nor uncomposited - however it would certainly an improvement (hopefully)
Tried https://forum.qt.io/topic/24701/solved-creating-a-qquickview-with-a-shared-opengl-context/5 ?

On theming, I had simply gone for a theme agnostic OSD design (since we "have" to use it in som places due to readability issues anyway)

I had tried something like that. The problem was that the QOpenGLContext for our compositing context and the QOpenGLContext for QtQuick just didn't want to share. It was somehow related to the way we create the context and Qt creates the context. As it worked for Wayland now the issue might have been fixed with Qt 5.4. Maybe I should get out the old branch ;-)

Git commit 3a1f11d21347032f7d1b8fd43d30ee7d3ce5ede0 by Thomas Lübking.
Committed on 14/09/2015 at 19:02.
Pushed by luebking into branch 'master'.

delay QuickTiling indication on inner screenborder

The user might just want to move the window from
one screen to another, no point in wasting time to
show the indicator
REVIEW: 125024
FIXED-IN: 5.5

M  +1    -0    client.cpp
M  +1    -0    client.h
M  +29   -8    events.cpp

http://commits.kde.org/kwin/3a1f11d21347032f7d1b8fd43d30ee7d3ce5ede0

*** Bug 354967 has been marked as a duplicate of this bug. ***

(In reply to Thomas Lübking from comment #11)
> Git commit 3a1f11d21347032f7d1b8fd43d30ee7d3ce5ede0 by Thomas Lübking.
> Committed on 14/09/2015 at 19:02.
> Pushed by luebking into branch 'master'.
> 
> delay QuickTiling indication on inner screenborder
> 
> The user might just want to move the window from
> one screen to another, no point in wasting time to
> show the indicator
> REVIEW: 125024
> FIXED-IN: 5.5
> 
> M  +1    -0    client.cpp
> M  +1    -0    client.h
> M  +29   -8    events.cpp
> 
> http://commits.kde.org/kwin/3a1f11d21347032f7d1b8fd43d30ee7d3ce5ede0

Hm im running on Arch and it seems that Windows still stutter when its enabled.

How fast do you move windows?
You'll have 250ms to get it across the active area (20px on either side of the edge) - otherwise the indicator is still created.

(In reply to Thomas Lübking from comment #14)
> How fast do you move windows?
> You'll have 250ms to get it across the active area (20px on either side of
> the edge) - otherwise the indicator is still created.

Not so slow, just a regular drag; here is a video I tried to do: https://www.youtube.com/watch?v=Exa8UwPiP1U&feature=youtu.be 

There is no indicator shown etc but it still feels and shows the stutter when dragging.

Best Regards

the video is marked private.
you can also attach it here or send it by mail

(In reply to Thomas Lübking from comment #16)
> the video is marked private.
> you can also attach it here or send it by mail

Oh sorry confused it with unlisted, its fixed now.

(In reply to Thomas Lübking from comment #16)
> the video is marked private.
> you can also attach it here or send it by mail

Oh sorry confused it with unlisted, its fixed now.