The window switching on Alt+Tab is rather slow because of all the animations. Sometimes when I quickly press Alt+Tab it simply does nothing, as if it misses the keypress. I tried to reduce the animation speed in System Settings but that affects speed of all animations instead of just window switching. There needs to be a much snappier window switcher as quick window switching is often done when actively working with multiple applications and delays and missed keypresses are unacceptable in this case. As an example of a much better responsiveness you might try working in XFCE for a while. I have never had problems with window switching there, although I admit the look of that DE is much simpler. But there are some areas where simplicity and responsiveness matter most in every day work. Reproducible: Always Kubuntu 15.10, x86_64, Nvidia drivers 355.11, Core i7 2600K, 980GTX, 16 GiB RAM, no swap.
Animations have *no* connection to actual window switching at all. Also releasing alt+tab very quickly will just toggle between window w/o even activating a tabbox. No idea what you encounter or concern, but the descrition is factually wrong in every aspect, sorry.
PS, in order to get closer to the issue, attach a screenshot of your tabbox settings (we seriously need to re-add that to the support info ;-)
(In reply to Thomas Lübking from comment #1) > Animations have *no* connection to actual window switching at all. > Also releasing alt+tab very quickly will just toggle between window w/o even > activating a tabbox. > > No idea what you encounter or concern, but the descrition is factually wrong > in every aspect, sorry. I described my experience with KDE, you're in no position to say it is factually wrong, sorry. My assertion that it is caused by animations may be wrong, I admit that. (In reply to Thomas Lübking from comment #2) > PS, in order to get closer to the issue, attach a screenshot of your tabbox > settings (we seriously need to re-add that to the support info ;-) Where can I find these settings? Do you mean the Desktop Effects?
(In reply to Lastique from comment #3) > I described my experience with KDE No, you attempted an analysis and that analysis /is/ factually wrong. Sorry. Please don't feel offended, but it's better to cut down such paths asap to not keep looking at the wrong position. > Where can I find these settings? Do you mean the Desktop Effects? No, "kcmshell5 kwintabbox"
Created attachment 95310 [details] Tabbox settings main tab
Created attachment 95311 [details] Tabbox settings alternative tab
Random guess: what if you change "breeze" to "cover flow" or "flip switch" (or deactivate the indirect representation altogether)?
I played around with different representations. "Cover Flow", "Flip Switch" and disabling representation make things significantly better. The animation is smooth and I didn't notice any lost Alt+Tab keypresses during my testing. All other modes have more or less the same performance as "Breeze", which was set by default. With most of them I noticed occasional loss of Alt+Tab, if pressed quickly. I can tell the keypress was actually registered as I can see the OK button on the KCM changes brightness slightly when I press Alt+Tab - both when the window is subsequently switched and not. Notably, all these modes display a glossy menu with some content, and this menu does feel sluggish - in some modes more than the others. I can see it appears and dissolves at a reduced frame rate compared to other animations. PS: A very useful config module, why is it not accessible through System Settings?
There is one minor problem with the "disabled representation" mode. Sometimes, when I switch between windows slowly and hold Alt for a long time I can see that portions of the window that was selected previously and is half-transparent now are blinking as if the frames from the fade out animation are stuck in a loop. Not sure if I noticed this when representations were enabled. Could this be caused by forcing triple buffering in kwin? I have these lines in /etc/environment: KWIN_TRIPLE_BUFFER=1 __GL_SYNC_TO_VBLANK=1 __GL_SYNC_DISPLAY_DEVICE="DFP-0" QSG_RENDER_LOOP=basic
(In reply to Lastique from comment #8) > All other modes have more or less the same performance as "Breeze" Translation: "QtSlow" issue, see eg. bug #352050 or bug #348577 - *VERYHUGESIGH* @Martin, move-is-hide dance once more? (though here I'm really reluctant, since the tabbox grabs input) > was set by default. With most of them I noticed occasional loss of Alt+Tab, > if pressed quickly. To bypass the tabbox altogether, you actually need to be *really* fast (on releasing alt+tab), then the used tabbox should not matter at all. I guess you run into the midst of the creation of the tabbox window. > PS: A very useful config module, why is it not accessible through System > Settings? It of course is (kcmshell is just a direct loader for Kde Config Modules ;-) -> Window management / Task switcher ("Task"! switcher??) (In reply to Lastique from comment #9) > Could this be caused by forcing triple buffering in kwin? More like because of re-using the old buffer and an insufficient repaint (the buffers are swapped "constantly" anyway, you're just not supposed to see that) - triple buffering only impacts kwins frameclock strategy. https://community.kde.org/KWin/Environment_Variables Can you specify a region pattern (upper side, lower right corner, frame around, square in the center, etc.)? > QSG_RENDER_LOOP=basic This could make QtSlow extra slow (on bad luck), try: QSG_RENDER_LOOP= kwin_x11 --replace &
(In reply to Thomas Lübking from comment #10) > > > With most of them I noticed occasional loss of Alt+Tab, > > if pressed quickly. > To bypass the tabbox altogether, you actually need to be *really* fast (on > releasing alt+tab), then the used tabbox should not matter at all. > I guess you run into the midst of the creation of the tabbox window. Yes, that's probably the case. Is it possible to buffer or proxy the input to the new tabbox window through whatever is handling the initial Alt+Tab keydown events, so that no input can be lost? > > PS: A very useful config module, why is it not accessible through System > > Settings? > It of course is (kcmshell is just a direct loader for Kde Config Modules ;-) > -> Window management / Task switcher ("Task"! switcher??) Doh! I was looking everywhere in the Appearance section. Thanks! :) > Can you specify a region pattern (upper side, lower right corner, frame > around, square in the center, etc.)? It's usually the window decoration that's blinking, typically the upper part - the window title and a little lower. I tried to record a screencast with the effect but it didn't show on the video. Odd... Perhaps I should create a separate bug for this? > > QSG_RENDER_LOOP=basic > This could make QtSlow extra slow (on bad luck), try: > QSG_RENDER_LOOP= kwin_x11 --replace & It's a workaround for System Settings and a few other KDE apps crashing. I'll try tomorrow if running without it helps.
(In reply to Lastique from comment #11) > Yes, that's probably the case. Is it possible to buffer or proxy the input > to the new tabbox window through whatever is handling the initial Alt+Tab > keydown events, so that no input can be lost? The input isn't "lost". It seems that in case of the first tabbox invocation (after selecting another QML tabbox, that is - no other case exposes this behavior), the tabbox starts at the current window (rather than the next) If you then release the shortcut, you accept the selected (previous and still current) window. > It's usually the window decoration that's blinking, typically the upper part > ... > Perhaps I should create a separate bug for this? Yes, please. Against effects-various (it's the highlight effect which would require some extra repaint)
> move-is-hide dance once more? rather not. I think here we just need to optimize. I'm currently using the Informative switcher and that shows instantly. So either Qt 5.6 improves the situation or the QML is easier. From investigating kscreenlocker: QML can block badly depending on the code. So I think the proper approach is to optimize the QML code.
Hmmm... > All other modes have more or less the same performance as "Breeze" > ... > Notably, all these modes display a glossy menu with some content Lastique, do you use the "air" plasma desktop theme? Does it perform better with the breeze theme? (In reply to Martin Gräßlin from comment #13) > QML can block badly depending on the code. So much for the benefits of declarative "programming" :-P > So I think the proper approach is to optimize the QML code. I recall the breeze declaration declaring an infinite recursion on the event loop (juggling the window size due to the slider), but this is on creation, so some statements make the QML compiler slow?? One important aspect could be the GL context creation (lastique is on the nvidia blob)
> so some statements make the QML compiler slow?? no, compilation is normally not the problem. It's more if too many objects are created or in a bad sequence (stuff shuffling around during creation). The first frame is delayed till the complete scene is created. So with clever loaders one can get it faster. Ideally what could be a solution is to create the view already when invoking Alt+Tab. That is use the 50 msec we don't show it anyway to create it.
(In reply to Thomas Lübking from comment #10) > > > QSG_RENDER_LOOP=basic > This could make QtSlow extra slow (on bad luck), try: > QSG_RENDER_LOOP= kwin_x11 --replace & I've tried to comment that line (the variable is not set anymore). The animation is probably slightly snappier, but I still occasionally get missed Alt+Tab (less than before). The problem is that I need that line to keep apps from crashing.
(In reply to Thomas Lübking from comment #12) > (In reply to Lastique from comment #11) > > > Yes, that's probably the case. Is it possible to buffer or proxy the input > > to the new tabbox window through whatever is handling the initial Alt+Tab > > keydown events, so that no input can be lost? > > The input isn't "lost". > It seems that in case of the first tabbox invocation (after selecting > another QML tabbox, that is - no other case exposes this behavior), the > tabbox starts at the current window (rather than the next) > If you then release the shortcut, you accept the selected (previous and > still current) window. I'd say the first Alt+Tab is more likely to be missed, yes. But I did see the subsequent Alt+Tabs missed too. That was with QSG_RENDER_LOOP=basic.
(In reply to Thomas Lübking from comment #14) > > Lastique, do you use the "air" plasma desktop theme? Yes. > Does it perform better with the breeze theme? Hmm, it looks pretty much the same to me. Maybe it's a bit faster but it's hard to tell if there is any difference. Misses keypresses just the same.
Can you try this patch to profile tabbox startup times on first and subsequent invocations? (lasts diff --git a/tabbox/tabboxhandler.cpp b/tabbox/tabboxhandler.cpp index b4f1713..0469ea5 100644 --- a/tabbox/tabboxhandler.cpp +++ b/tabbox/tabboxhandler.cpp @@ -48,6 +48,8 @@ along with this program. If not, see <http://www.gnu.org/licenses/>. #include <KPackage/Package> #include <KPackage/PackageLoader> +#include <QElapsedTimer> + namespace KWin { namespace TabBox @@ -308,13 +310,17 @@ QObject *TabBoxHandlerPrivate::createSwitcherItem(bool desktopMode) void TabBoxHandlerPrivate::show() { #ifndef KWIN_UNIT_TEST + QElapsedTimer profile; + profile.start(); if (m_qmlContext.isNull()) { qmlRegisterType<SwitcherItem>("org.kde.kwin", 2, 0, "Switcher"); m_qmlContext.reset(new QQmlContext(Scripting::self()->qmlEngine())); } + qDebug() << "1" << profile.elapsed(); if (m_qmlComponent.isNull()) { m_qmlComponent.reset(new QQmlComponent(Scripting::self()->qmlEngine())); } + qDebug() << "2" << profile.elapsed(); const bool desktopMode = (config.tabBoxMode() == TabBoxConfig::DesktopTabBox); auto findMainItem = [this](const QMap<QString, QObject *> &tabBoxes) -> QObject* { auto it = tabBoxes.constFind(config.layoutName()); @@ -323,6 +329,7 @@ void TabBoxHandlerPrivate::show() } return nullptr; }; + qDebug() << "3" << profile.elapsed(); m_mainItem = nullptr; m_mainItem = desktopMode ? findMainItem(m_desktopTabBoxes) : findMainItem(m_clientTabBoxes); if (!m_mainItem) { @@ -331,6 +338,7 @@ void TabBoxHandlerPrivate::show() return; } } + qDebug() << "4" << profile.elapsed(); if (SwitcherItem *item = switcherItem()) { if (!item->model()) { QAbstractItemModel *model = nullptr; @@ -346,6 +354,7 @@ void TabBoxHandlerPrivate::show() // everything is prepared, so let's make the whole thing visible item->setVisible(true); } + qDebug() << "5" << profile.elapsed(); #endif }
Created attachment 95369 [details] Log obtained with the patch in Comment #19 I attached the console output from kwin with the patch. I added dashes to the debug output. The log contains 5 Alt+Tabs. The first one was missed (i.e. no window switch happened), and it shows increased latencies. The other 4 were processed normally.
That matches my observation exactly, only the first usage is dog slow (and starts at the wrong index, thus your assumption of a "miss"; you simply switched from the current to the current window), the subsequent invocations are fine.
*** Bug 362120 has been marked as a duplicate of this bug. ***
I can confirm this bug. Sometimes alt-tab is not working. Sometimes it works ok. My settings: Compositor is switched off. task switcher: Show Selected Window: yes The effect to replace the list window when desktop effects are active: no plasmashell 5.8.7 distro: openSUSE Leap 42.3
Can we change the status of this bug to confirmed please?
(In reply to Teunizz from comment #24) > Can we change the status of this bug to confirmed please? Confirmed has no meaning to us developers.
This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23? I don't encounter any problems when quickly pressing ALT-TAB. Even keeping both keys pressed works fine for me.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This doesn't seem to happen for me anymore. Thanks! Operating System: Kubuntu 21.10 KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-21-lowlatency (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-2600K CPU @ 3.40GHz Memory: 15.6 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 Nvidia driver: 470.86