Today I upgraded from a rocking 4.14 that was running really well to KDE 5. I thought KDE 5 was going to rock even more, because all of that GLX and EGL, and cleaning stuff, and refactoring and ... etc etc etc. Then I actually tested it and I must say I'm completely disappointed. Kwin is not faster. It doesn't even have the same speed as in KDE4. It's actually killing my machine every time I resize a window. Video: http://youtu.be/yBxiBFyo_A8 BTW: Don't go the "hardware might be too slow" path. This is running on a 64GB RAM i7, 8 cores at 4,2Ghz and an NVIDIA SLI. This machine easily runs 10 virtual machines with a few Windows and Linux without even noticing it. Reproducible: Always
probably bug #343172 please attach the output of qdbus org.kde.KWin /KWin supportInformation a common pattern seems nvidia, but i've not seen such here. you may also check the things asked in the other bug (and if no success, that just stresses the duplicate factor)
support info: https://paste.kde.org/psdxx7lnq For me, Konsole is resizing quite well. Maybe a little bit tearing in the right border of the window, but it's for 0.1sec at most. The really bad stuff is resizing systemsettings. This literally eats my entire machine and takes anyware from 0.1sec to 20 seconds to redraw the window.
Ok, so rather not a duplicate (as the other bug claims to have this issue w/ even xterm and/or compositing and the resize effect enabled) This will be rather a bug about systemsettings and/or the QQuickWidget (which also causes the black block in the center of the window) If you quit systemsettings and run kcmshell5 kwindecoration the black block should be gone -> is the resize behavior similar for that window? Please notice that according to the supportInformation compositing is NOT available. Also please notice that egl is not supported by the nvidia blob so far (but for GLES, but with Qt5 you either buy into GLES or GLX, you cannot have both together - that's a downstream decision)
The black box is gone, indeed, and the resizing is good now. About the GLX vs EGL... ok... which one should I use if I'm using NVIDIA's binary driver?
GLX - your only choice (Arch Qt5 isn't compiled for GLES) It's however picked implicitly (or should be, resp. if you try to enforce EGL, you simply will end up w/o compositing) *** This bug has been marked as a duplicate of bug 341971 ***
Well... that's funny, because I'm able to select from between all the options! That is, OpenGL 2.0, 3.1, XRender and both EGL and XGL, and nothing happens at all when I click on "apply" after choosing each option. Shouldn't those option be disabled/hidden if I'm not supposed to use them if I can't?
"It does™", but the situation w/ egl is not that simple. EGL *is* available w/ the nvidia blob, but simply does not work other than for GLES. We could in theory blacklist the nvidia blob, but then it's a bug as soon as EGL on X works with the blob... Therefore, when you select EGL a yellow box should appear and tell you that "EGL is not supported by all OpenGL drivers. If not supported the Compositor will be disabled."