356938 2015-12-20 10:18:38 +0000 Worse performance with KDE than Gnome when playing CS GO 2016-02-16 13:40:05 +0000 1 1 4 Plasma plasmashell Task Manager and Icons-Only Task Manager widgets 5.5.1 Other Linux RESOLVED FIXED https://bugs.kde.org/show_bug.cgi?id=356366 NOR normal 1.0 0 anakin.cs hein bshah illumilore kde lukycrociato plasma-bugs-null thomas.luebking http://commits.kde.org/plasma-framework/c64a94a265acd5003fbbb4e3abc7fdb72726b4c3 0 oldest_to_newest 1564776 0 anakin.cs 2015-12-20 10:18:38 +0000 I am not sure if this bug should be filled against kwin or plasmashell. I am on ArchLinux with Plasma 5.5.1. I play CS GO quite often, and I have around 110-120 FPS with KDE, with drops below 100 that can sometimes go to 60-70 or below, depending of what's going on in the game. Yesterday, I decided to try with Gnome, and I was quite surprised with the result, I would get 160 FPS in areas where I get 120 FPS with KDE! The game also felt much more smooth, I would never get any drops below 100 FPS. Now, I am not sure how to find what's causing this performance gap, I have tried to disable compositing in KDE (Alt+Shift+F12), this made no difference to the in-game FPS. I am on a laptop with an optimus setup, the nvidia card is a Nvidia GeForce GTX 850M, so I am running the game through primusrun. Please do not tell me that anything above 60 FPS is useless, this is simply not true for Source engine games. Frames are not only used for drawing, but also for networking, input, etc, and you need at least 128+ FPS in CS GO to have the maximum network performance. Anyway, as I said, I have drops below 60 FPS. Reproducible: Always 1564783 1 thomas.luebking 2015-12-20 10:32:22 +0000 > Now, I am not sure how to find what's causing this performance gap, I have tried to disable compositing in KDE (Alt+Shift+F12), this made no difference to the in-game FPS. So, kwin is pretty much likely *not* the reason (does it run on the nvidia or the intel chip btw?) Did you check CPU load of (other, desktop related) processes (baloo?) Did you try to kill plasmashell? (keep yourself a konsole open ;-) Also dump the environment of the game process: tr '\0' '\n' < /proc/[cs pid here]/environ 1564786 2 anakin.cs 2015-12-20 10:47:00 +0000 kwin runs on the intel chip. baloo is disabled. The only processes that seem to use CPU are the game, Steam and plasmashell. I have tried to kill plasmashell, and it looks like the FPS immediately went to the same level as Gnome! Then, something interesting I could reproduce multiple times: 1) ALT-F2 -> plasmashell 2) I go back to CS GO, the performance is still the best one 3) I ALT-TAB back to desktop, then go back to CS GO, the performance is back to the "bad one" I have to kill plasmashell again to get the best performance, and can launch it once again, but if I then ALT-TAB out from the game, it brings the bad performance back. 1564787 3 96208 anakin.cs 2015-12-20 10:47:40 +0000 Created attachment 96208 CS GO environment variables 1564788 4 anakin.cs 2015-12-20 10:49:23 +0000 Apparently I might not be the only one with the same issue: https://bugs.kde.org/show_bug.cgi?id=356366 1564793 5 anakin.cs 2015-12-20 11:03:01 +0000 Please note that I also need to disable compositing to have the same perf as Gnome. So basically, two issues: 1) The performance issue caused by ALT-TAB and requiring me to kill plasmashell 2) Compositing, which is also causing some performance loss in the game (although less than the first issue). I guess that could be solved with "Suspend compositor for fullscreen window"? Unfortunately since the main card is an intel card, the option is unavailable for me. 1564797 6 thomas.luebking 2015-12-20 11:11:11 +0000 Sounds indeed like an exact duplicate, but on different HW/driver. Try to export __GL_YIELD="NOTHING" for the game, but since plasmashell will likely run on the intel chip as well, that *should* not be too troublesome. It will rather be because of the optimus pipe being blocked on the intel side because of "things plasmashell does in its opengl context™" As a quick solution for the WE, simply pkill -SIGTOP plasmashell # run game pkill -CONT plasmashell would hopefully do? Alternatively, can you disable optimus and run the nvidia GPU exclusively, resp. only optirun palsmashell as well (maybe it does better on switching/sharing active contexts)? 1564802 7 thomas.luebking 2015-12-20 11:15:03 +0000 As for the kwin side, set up a rule to block compositing for the window. See bug #348156 for further discussions on this (aside similar context sharing issues, kwin also caps MaxFPS and sync'd swaps) 1564803 8 thomas.luebking 2015-12-20 11:16:18 +0000 PS: > __GL_THREADED_OPTIMIZATIONS=1 Is that set by steam or yourself? Can you get rid of it? 1564810 9 anakin.cs 2015-12-20 11:43:11 +0000 export __GL_YIELD="NOTHING" doesn't seem to change anything Sending the STOP signal to plasmashell seem to work. Running everything on the nvidia GPU isn't really a solution, I used to do this but this kill the battery, and make the fans spin faster. Tried to "primusrun plasmashell", and the bug is still present, it doesn't help. I am seeing the same behaviour as in bug #356366, if I click on the CS GO window to come back from the ALT-TAB, I get the bug, but if I over some other icon on the task bar (like Dolphin) and use ALT-TAB to get back in-game, I don't have the bug. I went to kwin window rules, but I can't find any option to block compositing for the window. Or maybe it's called differently here? __GL_THREADED_OPTIMIZATIONS=1 is set in the game launch script by default in all Source games, because there is a "Multicore rendering" option in the game settings which improve FPS and works with it. If I get rid of it, I would surely have lower FPS as that option would no longer work. 1564854 10 thomas.luebking 2015-12-20 14:33:33 +0000 (In reply to AnAkkk from comment #9) > Running everything on the nvidia GPU isn't really a solution I rather meant "for a test" - to see whether it's optimus related reg. management of multiple contexts. > I am seeing the same behaviour as in bug #356366, if I click on the CS GO > window to come back from the ALT-TAB, I get the bug, but if I hover some > other icon on the task bar (like Dolphin) and use ALT-TAB to get back > in-game, I don't have the bug. Hovering will likely get you a tooltip (becoming the active plasmashell context) and when switching, the tooltip closes (and the active/dominant context becomes the game) > I went to kwin window rules, but I can't find any option to block > compositing for the window. Or maybe it's called differently here? Last tab (appearance and fixes), last item "block compositing" (I've unfortunately no idea how it's called in the french translation) > __GL_THREADED_OPTIMIZATIONS=1 is set in the game launch script by default in While __GL_THREADED_OPTIMIZATIONS should get you a benefit on multicore systems, I doubt it has actual impact on multicore rendering (which should work just as much) Also I meant "for trying impact" - and you'd still rather get superior rendering compared to the present situation (if that has impact on the problem, we don't yet know the actual problem - except for maybe trouble on GL context management; apparently it's not limited to optimus - the other bug is iirc on fglrx) 1564860 11 anakin.cs 2015-12-20 15:02:09 +0000 (In reply to Thomas Lübking from comment #10) > (In reply to AnAkkk from comment #9) > > Running everything on the nvidia GPU isn't really a solution > > I rather meant "for a test" - to see whether it's optimus related reg. > management of multiple contexts. > I'll try running everything on the Nvidia card later, this is a bit annoying to setup. > > I went to kwin window rules, but I can't find any option to block > > compositing for the window. Or maybe it's called differently here? > > Last tab (appearance and fixes), last item "block compositing" (I've > unfortunately no idea how it's called in the french translation) I see, the translation doesn't really match, it actually says "Compositing by blocks" in French :D (like "a block of wood") I just tried this option, and it sent a SIGSTOP message the kwin_x11 process apparently, making me totally unable to ALT-TAB, and even after putting back kwin_x11 in a normal state, it just wouldn't work, I had to use kwin_x11 --replace. > > __GL_THREADED_OPTIMIZATIONS=1 is set in the game launch script by default in > > While __GL_THREADED_OPTIMIZATIONS should get you a benefit on multicore > systems, I doubt it has actual impact on multicore rendering (which should > work just as much) Removing __GL_THREADED_OPTIMIZATIONS doesn't actually change anything, it doesn't solve the issue and doesn't change the FPS either apparently. 1564869 12 thomas.luebking 2015-12-20 15:47:41 +0000 (In reply to AnAkkk from comment #11) > I see, the translation doesn't really match, it actually says "Compositing > by blocks" in French :D (like "a block of wood") *lol* - no, tile based deferred rendering is an attribute of the hardware, we cannot control that ;-) Can you please file a bug against i18n/french? > I just tried this option, and it sent a SIGSTOP message the kwin_x11 process > apparently No, that's drkonqi - kwin apparently crashed, but that won't be related to the setting (coincident) (see bug #353428) - SIGCONT will then just abort the kwin process (you may now have a stale drkonqi process around) 1564871 13 anakin.cs 2015-12-20 16:00:22 +0000 (In reply to Thomas Lübking from comment #12) > Can you please file a bug against i18n/french? Should it be frameworks-ki18n or ki18n? > > I just tried this option, and it sent a SIGSTOP message the kwin_x11 process > > apparently > No, that's drkonqi - kwin apparently crashed, but that won't be related to > the setting (coincident) (see bug #353428) - SIGCONT will then just abort > the kwin process (you may now have a stale drkonqi process around) Indeed, I do have a drkonqi process. It crashes every time I try to use that setting though. I have tried to run everything in the nvidia card, but it's not actually possible anymore due to a bug in Xorg 1.18, which requires me to use a workaround, but then all windows are unusable, including the game menus (no cursor), see https://bugs.archlinux.org/task/47151 I tried to downgrade Xorg, but then I had files conflicting with my Nvidia packages...so I ended up just reverting all changes I've made :/ 1564876 14 thomas.luebking 2015-12-20 16:59:37 +0000 (In reply to AnAkkk from comment #13) > Should it be frameworks-ki18n or ki18n? Just "i18n" - ki18n is the translation infrastructure, not the translated strings. I filed a bug and attached you, I cannot really handle this (my french is by far not good enough to lector others ;-) > Indeed, I do have a drkonqi process. It crashes every time I try to use that > setting though. Can you gdb into the stopped kwin process and obtain a backtrace? echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope # allow attaching gdb gdb --pid PID_OF_STOPPED_KWIN 2>&1 | tee stopped_kwin.gdb thread apply all bt 1564878 15 anakin.cs 2015-12-20 17:06:48 +0000 (In reply to Thomas Lübking from comment #14) > Just "i18n" - ki18n is the translation infrastructure, not the translated > strings. > I filed a bug and attached you, I cannot really handle this (my french is by > far not good enough to lector others ;-) Thanks :) > echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope # allow attaching gdb > gdb --pid PID_OF_STOPPED_KWIN 2>&1 | tee stopped_kwin.gdb > thread apply all bt Thread 4 (Thread 0x7fb6d52af700 (LWP 3797)): #0 0x00007fb6ec88f18d in poll () from /usr/lib/libc.so.6 #1 0x00007fb6eab7fae2 in ?? () from /usr/lib/libxcb.so.1 #2 0x00007fb6eab81757 in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x00007fb6d5b51379 in ?? () from /usr/lib/libQt5XcbQpa.so.5 #4 0x00007fb6eae3db8e in ?? () from /usr/lib/libQt5Core.so.5 #5 0x00007fb6ecb5a4a4 in start_thread () from /usr/lib/libpthread.so.0 #6 0x00007fb6ec89813d in clone () from /usr/lib/libc.so.6 Thread 3 (Thread 0x7fb6cf678700 (LWP 3845)): #0 0x00007fb6ec890e23 in select () from /usr/lib/libc.so.6 #1 0x00007fb6eb070c1f in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () from /usr/lib/libQt5Core.so.5 #2 0x00007fb6eb0726f7 in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timespec*) () from /usr/lib/libQt5Core.so.5 #3 0x00007fb6eb072bfe in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #4 0x00007fb6eb01c57a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #5 0x00007fb6eae38be4 in QThread::exec() () from /usr/lib/libQt5Core.so.5 #6 0x00007fb6e5af8055 in ?? () from /usr/lib/libQt5Qml.so.5 #7 0x00007fb6eae3db8e in ?? () from /usr/lib/libQt5Core.so.5 #8 0x00007fb6ecb5a4a4 in start_thread () from /usr/lib/libpthread.so.0 #9 0x00007fb6ec89813d in clone () from /usr/lib/libc.so.6 Thread 2 (Thread 0x7fb6ccac8700 (LWP 3855)): #0 0x00007fb6ecb6007f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x00007fb6e9fa1934 in ?? () from /usr/lib/libQt5Script.so.5 #2 0x00007fb6e9fa1979 in ?? () from /usr/lib/libQt5Script.so.5 #3 0x00007fb6ecb5a4a4 in start_thread () from /usr/lib/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #4 0x00007fb6ec89813d in clone () from /usr/lib/libc.so.6 Thread 1 (Thread 0x7fb6ecfa7840 (LWP 3796)): #0 0x00007fb6ec86791d in nanosleep () from /usr/lib/libc.so.6 #1 0x00007fb6ec8677b4 in sleep () from /usr/lib/libc.so.6 #2 0x00007fb6e5617d8a in ?? () from /usr/lib/libKF5Crash.so.5 #3 0x00007fb6e561821b in KCrash::defaultCrashHandler(int) () from /usr/lib/libKF5Crash.so.5 #4 <signal handler called> #5 0x00007fb6ec44cdfd in ?? () from /usr/lib/libkwin.so.5 #6 0x00007fb6eb04e200 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5 #7 0x00007fb6eb9119ac in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #8 0x00007fb6eb916e86 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 #9 0x00007fb6eb01ebab in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 #10 0x00007fb6eb020fa6 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5 #11 0x00007fb6eb072ac2 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #12 0x00007fb6d5bb821d in ?? () from /usr/lib/libQt5XcbQpa.so.5 #13 0x00007fb6eb01c57a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 #14 0x00007fb6eb02453c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5 #15 0x00007fb6ecd757cb in kdemain () from /usr/lib/libkdeinit5_kwin_x11.so #16 0x00007fb6ec7cf610 in __libc_start_main () from /usr/lib/libc.so.6 #17 0x00000000004007c9 in _start () Unfortunately there are no debug symbols on Arch :/ 1564879 16 anakin.cs 2015-12-20 17:21:12 +0000 I removed the "strip" option and recompiled kwin: #5 0x00007f14261c462d in KWin::SceneOpenGLShadow::~SceneOpenGLShadow() () from /usr/lib/libkwin.so.5 1564885 17 anakin.cs 2015-12-20 17:49:16 +0000 From what I can see it's crashing because the "effects" pointer is NULL inside the SceneOpenGLShadow::~SceneOpenGLShadow destructor. 1564951 18 thomas.luebking 2015-12-20 21:23:22 +0000 (In reply to AnAkkk from comment #17) > From what I can see it's crashing because the "effects" pointer is NULL > inside the SceneOpenGLShadow::~SceneOpenGLShadow destructor. Ewwww. It somehow updates its shadow on creation (god knows why) Can you try diff --git a/shadow.cpp b/shadow.cpp index 99f89bf..6963334 100644 --- a/shadow.cpp +++ b/shadow.cpp @@ -338,7 +338,7 @@ bool Shadow::updateShadow() m_topLevel->effectWindow()->sceneWindow()->updateShadow(0); m_topLevel->effectWindow()->buildQuads(true); } - deleteLater(); +// deleteLater(); }; if (m_decorationShadow) { if (Client *c = qobject_cast<Client*>(m_topLevel)) { This will leak, but if it doesn't crash we know a) the cause b) effects isn't reliable on the destructor (so checking it is justified - i'd prefer to not poke around and test "if (effects)" w/o actually knowing why it can be nullptr here) Thanks for the investigation. 1564973 19 anakin.cs 2015-12-20 23:13:53 +0000 Thanks, this patch actually fix the crash :) Now it correctly disables compositing when launching CS GO. 1564977 20 thomas.luebking 2015-12-20 23:25:20 +0000 Thanks for testing, please revert that patch and use https://git.reviewboard.kde.org/r/126441/ instead. 1564982 21 anakin.cs 2015-12-20 23:32:44 +0000 Ok :) Do you have any idea how I can debug the plasmashell performance issue? 1564991 22 thomas.luebking 2015-12-21 01:07:20 +0000 Localize it in the known oddity. Is it the taskbar tooltip (disable it and check whether the trick still works) or just the hover. Is it maybe actually the taskbar (remove it). 1565080 23 anakin.cs 2015-12-21 13:45:43 +0000 Disabled the taskbar tooltip, the bug is still present. As long as I hover on "CS GO" in the taskbar, and: 1) click to put the game in front or 2) alt-tab to put the game in front the bug appears. If I hover anything else in the task bar (an icon of a not running program, or any running app other than CS GO), and then ALT-TAB back into the game, it fixes the bug. 1565116 24 thomas.luebking 2015-12-21 15:21:28 +0000 Sounds a lot like the taskbar reaction to hovering a particular entry/entry with certain attributes. Is the game minimized at this time? Does it affect other minimized taskbar entries? Is it the active window (would eg. activating sth. else like xterm or so change something)? 1565145 25 anakin.cs 2015-12-21 16:30:37 +0000 (In reply to Thomas Lübking from comment #24) > Sounds a lot like the taskbar reaction to hovering a particular entry/entry > with certain attributes. > Is the game minimized at this time? Yes, when I ALT-TAB it minimizes it, I can't click on the task bar if it's not minimized. > Does it affect other minimized taskbar entries? What do you mean? Other entries are not games, so I can't really see any framerate change. > Is it the active window (would eg. activating sth. else like xterm or so > change something)? I'm not sure what you mean, if I'm in-game, shouldn't it be the active window? 1565150 26 thomas.luebking 2015-12-21 17:02:39 +0000 (In reply to AnAkkk from comment #25) > What do you mean? Other entries are not games, so I can't really see any > framerate change. I meant "what if you hover the taskbar button of another minimized window" (oc. if you should only show minimized windows in the taskbar, that's answered) > I'm not sure what you mean, if I'm in-game, shouldn't it be the active > window? Game -> alt+tab -> activate "something" (eg. xterm should be unsuspicious) -> hover the games taskbar entry -> activate the game (in either way, alt+tab or click the taskbar button) Assigning to taskbar, since it seems to be the culprit ("somehow") Btw, does it also happen with the "icons-only" taskbar? 1565154 27 hein 2015-12-21 17:08:49 +0000 Can someone sum up how exactly the Task Manager is supposed to be involved here? 26 comments is a lot to read. 1565155 28 anakin.cs 2015-12-21 17:15:41 +0000 (In reply to Thomas Lübking from comment #26) > I meant "what if you hover the taskbar button of another minimized window" > (oc. if you should only show minimized windows in the taskbar, that's > answered) Minimized or not, this fixes the issue, as in comment #23, as long as I over anything else than CS GO. > Game -> alt+tab -> activate "something" (eg. xterm should be unsuspicious) > -> hover the games taskbar entry -> activate the game (in either way, > alt+tab or click the taskbar button) Alt-tabbed, I launched xterm through the task bar, then hovered the game taskbar entry, and I had the bug again when going back in-game. > Btw, does it also happen with the "icons-only" taskbar? I have added an icons-only taskbar, and the issue is exactly the same. What I actually noticed is that I need to apply my "fix" to both taskbars, otherwise I get the issue. This means I need to hover something else than CS GO on both taskbars. 1565156 29 anakin.cs 2015-12-21 17:21:26 +0000 Also tried to hover another window on the task bar, and to use the mouse wheel to switch between windows, and it fixes the bug since I am hovering something else. If I hover CS GO and do the same, I have the same issue again. So apparently as long as the last hovered window on the taskbar is the CS GO, in any case, I get the performance issue. 1565215 30 thomas.luebking 2015-12-21 22:03:13 +0000 errrr... Eike, why do i see a live preview in the taskbar tooptip *even with compositing disabled*? Does the taskbar redirect windows itself (in doubt)? 1565216 31 hein 2015-12-21 22:10:27 +0000 AFAIK yes, the WindowThumbnail component (written by Martin) doesn't need kwin. 1565225 32 kde 2015-12-21 22:31:23 +0000 Yes, WindowThumbnail hooks into Composite on its own. 1565254 33 thomas.luebking 2015-12-22 00:26:55 +0000 Sounds suspicious enough (despite disabling tooltips seems to make no difference; i'd assume the window is redirected as long as the entry is hovered and it misses the leave event when the FS window kicks above it) @AnAkk, find /usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml and in there the PlasmaCore.ToolTipArea branch (line 166-212 here) Comment or delete it (keep a copy ;-) Restart plasmashell and see what happens. 1565255 34 thomas.luebking 2015-12-22 00:29:07 +0000 PS, comment works C-style /* PlasmaCore.ToolTipArea { blablablah; } */ 1565357 35 anakin.cs 2015-12-22 15:08:39 +0000 I can confirm that this also fixes the issue :) 1565373 36 thomas.luebking 2015-12-22 15:34:51 +0000 So, despite being disabled by setting, the model for the toolbuttons is still created and apparently queried (causing the overhead that explains the FPS drop) Why am I not surprised? Given the past descriptions, it's also that some index is always current (and thus the related window is redirected) - that's why one has to hover some other taskbar entry (to redirect that window, which will not mess with the games gl context, nor likely cause damage events at 120Hz) Setting "currentIndex: -1" when the tooltip closes (or, in doubt, when the pointer leaves the taskbar) should likely do, but how does one "declare" such? (Does one at all?) 1565380 37 mklapetek 2015-12-22 16:20:31 +0000 *** Bug 356366 has been marked as a duplicate of this bug. *** 1565404 38 hein 2015-12-22 18:27:47 +0000 Git commit c64a94a265acd5003fbbb4e3abc7fdb72726b4c3 by Eike Hein. Committed on 22/12/2015 at 18:26. Pushed by hein into branch 'master'. Stop redirecting windows when item is disabled or hidden. Concretely fixes Task Manager tooltips slowing down app rendering even after the tooltip is hidden. REVIEW:126475 M +19 -1 src/declarativeimports/core/windowthumbnail.cpp http://commits.kde.org/plasma-framework/c64a94a265acd5003fbbb4e3abc7fdb72726b4c3 1565405 39 hein 2015-12-22 18:28:11 +0000 See also https://quickgit.kde.org/?p=plasma-desktop.git&a=commit&h=ae00bbea02dd4b245efc00571840ecdbc7d3da4c 1565407 40 anakin.cs 2015-12-22 18:44:46 +0000 Thanks for the fix :) 1567324 41 kde 2016-01-04 12:52:17 +0000 *** Bug 354372 has been marked as a duplicate of this bug. *** 1568413 42 anakin.cs 2016-01-09 12:39:33 +0000 (In reply to Thomas Lübking from comment #20) > Thanks for testing, please revert that patch and use > https://git.reviewboard.kde.org/r/126441/ instead. Is there any thing new on merging this? :) 1568414 43 thomas.luebking 2016-01-09 12:44:03 +0000 (In reply to AnAkkk from comment #42) > Is there any thing new on merging this? :) not been approved yet - i guess martin's still catching up x-mas vacancies. 1577031 44 thomas.luebking 2016-02-16 13:40:05 +0000 Git commit cae90bb035e6170a9beb38545cf60e31af612804 by Thomas Lübking. Committed on 16/02/2016 at 12:59. Pushed by luebking into branch 'master'. catch nullptr effects when deleting shadows the shadow can be deleted deferred from an update there's a slight chance, to be eg. triggered by clients blocking compositing, that the compositor is suspended in the same cycle and the effects pointer (and scene and context) thus gone FIXED-IN: 5.6 REVIEW: 126441 M +5 -3 scene_opengl.cpp http://commits.kde.org/kwin/cae90bb035e6170a9beb38545cf60e31af612804 96208 2015-12-20 10:47:40 +0000 2015-12-20 10:47:40 +0000 CS GO environment variables csgo_env.txt text/plain 3573 anakin.cs WERHX1ZUTlI9MQptdWx0aXRocmVhZF9nbHNsX2NvbXBpbGVyPTEKS0RFX01VTFRJSEVBRD1mYWxz ZQpYREdfU0VTU0lPTl9JRD1jMgpzdXBwcmVzc19yZXN0YXJ0PTEKU0hFTEw9L2Jpbi9iYXNoCkdU SzJfUkNfRklMRVM9L2V0Yy9ndGstMi4wL2d0a3JjOi9ob21lL3VzZXIvLmd0a3JjLTIuMDovaG9t ZS91c2VyLy5jb25maWcvZ3RrcmMtMi4wClNURUFNX1JVTlRJTUU9MApMRF9QUkVMT0FEPTovaG9t ZS91c2VyLy5sb2NhbC9zaGFyZS9TdGVhbS91YnVudHUxMl8zMi9nYW1lb3ZlcmxheXJlbmRlcmVy LnNvOi9ob21lL3VzZXIvLmxvY2FsL3NoYXJlL1N0ZWFtL3VidW50dTEyXzY0L2dhbWVvdmVybGF5 cmVuZGVyZXIuc28KU0RMX0dBTUVDT05UUk9MTEVSQ09ORklHPTAzMDAwMDAwZGUyODAwMDBmZjEx MDAwMDAxMDAwMDAwLFZhbHZlIFN0cmVhbWluZyBHYW1lcGFkLGE6YjAsYjpiMSxiYWNrOmI2LGRw ZG93bjpoMC40LGRwbGVmdDpoMC44LGRwcmlnaHQ6aDAuMixkcHVwOmgwLjEsZ3VpZGU6YjgsbGVm dHNob3VsZGVyOmI0LGxlZnRzdGljazpiOSxsZWZ0dHJpZ2dlcjphMixsZWZ0eDphMCxsZWZ0eTph MSxyaWdodHNob3VsZGVyOmI1LHJpZ2h0c3RpY2s6YjEwLHJpZ2h0dHJpZ2dlcjphNSxyaWdodHg6 YTMscmlnaHR5OmE0LHN0YXJ0OmI3LHg6YjIseTpiMywKMDMwMDAwMDBkZTI4MDAwMGZjMTEwMDAw MDEwMDAwMDAsU3RlYW0gQ29udHJvbGxlcixhOmIwLGI6YjEsYmFjazpiNixkcGRvd246aDAuNCxk cGxlZnQ6aDAuOCxkcHJpZ2h0OmgwLjIsZHB1cDpoMC4xLGd1aWRlOmI4LGxlZnRzaG91bGRlcjpi NCxsZWZ0c3RpY2s6YjksbGVmdHRyaWdnZXI6YTIsbGVmdHg6YTAsbGVmdHk6YTEscmlnaHRzaG91 bGRlcjpiNSxyaWdodHN0aWNrOmIxMCxyaWdodHRyaWdnZXI6YTUscmlnaHR4OmEzLHJpZ2h0eTph NCxzdGFydDpiNyx4OmIyLHk6YjMsCkdUS19SQ19GSUxFUz0vZXRjL2d0ay9ndGtyYzovaG9tZS91 c2VyLy5ndGtyYzovaG9tZS91c2VyLy5jb25maWcvZ3RrcmMKR1NfTElCPS9ob21lL3VzZXIvLmZv bnRzCk9MRFBXRD0vaG9tZS91c2VyLy5sb2NhbC9zaGFyZS9TdGVhbS9TdGVhbUFwcHMvY29tbW9u L0NvdW50ZXItU3RyaWtlIEdsb2JhbCBPZmZlbnNpdmUKX19HTF9OT19EU09fRklOQUxJWkVSPTEK R1RLX01PRFVMRVM9Y2FuYmVycmEtZ3RrLW1vZHVsZQpBTlRfSE9NRT0vdXNyL3NoYXJlL2FwYWNo ZS1hbnQKWERHX1NFU1NJT05fQ0xBU1M9dXNlcgpLREVfRlVMTF9TRVNTSU9OPXRydWUKVVNFUj11 c2VyCl9fR0xfVEhSRUFERURfT1BUSU1JWkFUSU9OUz0xClhDVVJTT1JfU0laRT0wCkxEX0xJQlJB UllfUEFUSD0vaG9tZS91c2VyLy5sb2NhbC9zaGFyZS9TdGVhbS9TdGVhbUFwcHMvY29tbW9uL0Nv dW50ZXItU3RyaWtlIEdsb2JhbCBPZmZlbnNpdmUvYmluOi91c3IvJExJQi9wcmltdXM6L2hvbWUv dXNlci8ubG9jYWwvc2hhcmUvU3RlYW0vdWJ1bnR1MTJfMzI6L2hvbWUvdXNlci8ubG9jYWwvc2hh cmUvU3RlYW0vdWJ1bnR1MTJfMzIvcGFub3JhbWE6Oi91c3IvbGliMzI6L2hvbWUvdXNlci8ubG9j YWwvc2hhcmUvU3RlYW0vdWJ1bnR1MTJfMzI6L2hvbWUvdXNlci8ubG9jYWwvc2hhcmUvU3RlYW0v dWJ1bnR1MTJfNjQ6L2hvbWUvdXNlci8ubG9jYWwvc2hhcmUvU3RlYW0vU3RlYW1BcHBzL2NvbW1v bi9Db3VudGVyLVN0cmlrZSBHbG9iYWwgT2ZmZW5zaXZlOi9ob21lL3VzZXIvLmxvY2FsL3NoYXJl L1N0ZWFtL1N0ZWFtQXBwcy9jb21tb24vQ291bnRlci1TdHJpa2UgR2xvYmFsIE9mZmVuc2l2ZS9i aW4KU1lTVEVNX1BBVEg9L3Vzci9sb2NhbC9zYmluOi91c3IvbG9jYWwvYmluOi91c3IvYmluOi91 c3IvbGliL2p2bS9kZWZhdWx0L2JpbjovdXNyL2Jpbi9zaXRlX3Blcmw6L3Vzci9iaW4vdmVuZG9y X3Blcmw6L3Vzci9iaW4vY29yZV9wZXJsClhER19TRVNTSU9OX1BBVEg9L29yZy9mcmVlZGVza3Rv cC9EaXNwbGF5TWFuYWdlci9TZXNzaW9uMQpYREdfU0VBVF9QQVRIPS9vcmcvZnJlZWRlc2t0b3Av RGlzcGxheU1hbmFnZXIvU2VhdDAKU0VTU0lPTl9NQU5BR0VSPWxvY2FsL2xhcHRvcDpAL3RtcC8u SUNFLXVuaXgvMTQwNix1bml4L2xhcHRvcDovdG1wLy5JQ0UtdW5peC8xNDA2ClN0ZWFtU3RyZWFt aW5nSGFyZHdhcmVFbmNvZGluZ05WSURJQT0wCk1PWl9QTFVHSU5fUEFUSD0vdXNyL2xpYi9tb3pp bGxhL3BsdWdpbnMKTUFWRU5fT1BUUz0tWG14NTEybQpTdGVhbVN0cmVhbWluZ0hhcmR3YXJlRW5j b2RpbmdJbnRlbD0wClN0ZWFtR2FtZUlkPTczMApNQUlMPS92YXIvc3Bvb2wvbWFpbC91c2VyClBB VEg9L3Vzci9sb2NhbC9zYmluOi91c3IvbG9jYWwvYmluOi91c3IvYmluOi91c3IvbGliL2p2bS9k ZWZhdWx0L2JpbjovdXNyL2Jpbi9zaXRlX3Blcmw6L3Vzci9iaW4vdmVuZG9yX3Blcmw6L3Vzci9i aW4vY29yZV9wZXJsCkRFU0tUT1BfU0VTU0lPTj0vdXNyL3NoYXJlL3hzZXNzaW9ucy9wbGFzbWEK U3RlYW1MYXVuY2hlclVJPQpIRz0vdXNyL2Jpbi9oZwpYREdfU0VTU0lPTl9UWVBFPXgxMQpQV0Q9 L2hvbWUvdXNlci8ubG9jYWwvc2hhcmUvU3RlYW0vU3RlYW1BcHBzL2NvbW1vbi9Db3VudGVyLVN0 cmlrZSBHbG9iYWwgT2ZmZW5zaXZlClNETF9WSURFT19YMTFfREdBTU9VU0U9MApTVEVBTV9DTElF TlRfQ09ORklHX0ZJTEU9L2hvbWUvdXNlci8ubG9jYWwvc2hhcmUvU3RlYW0vc3RlYW0uY2ZnCkxB Tkc9ZnJfRlIuVVRGLTgKS0RFX1NFU1NJT05fVUlEPTEwMDAKdmJsYW5rX21vZGU9MApTdGVhbVN0 cmVhbWluZ0hhcmR3YXJlRW5jb2RpbmdBTUQ9MApTWVNURU1fTERfTElCUkFSWV9QQVRIPQpTVEVB TVNDUklQVD0vdXNyL2Jpbi9zdGVhbQpTdGVhbUFwcElkPTczMApTU0hfQVNLUEFTUz0vdXNyL2Jp bi9rc3NoYXNrcGFzcwpTdGVhbTNNYXN0ZXI9MTI3LjAuMC4xOjU3MzQzClNITFZMPTQKWERHX1NF QVQ9c2VhdDAKR0RLX0NPUkVfREVWSUNFX0VWRU5UUz0xCkhPTUU9L2hvbWUvdXNlcgpLREVfU0VT U0lPTl9WRVJTSU9OPTUKU1RFQU1TQ1JJUFRfVkVSU0lPTj0xMDAwNTEKWENVUlNPUl9USEVNRT1i cmVlemVfY3Vyc29ycwpTdGVhbU5vT3ZlcmxheVVJPTAKTE9HTkFNRT11c2VyClhER19TRVNTSU9O X0RFU0tUT1A9S0RFClN0ZWFtVGVuZm9vdD0wCkRCVVNfU0VTU0lPTl9CVVNfQUREUkVTUz11bml4 OnBhdGg9L3J1bi91c2VyLzEwMDAvYnVzClFUX0xPR0dJTkdfUlVMRVM9Ki5kZWJ1Zz1mYWxzZQpY REdfREFUQV9ESVJTPS91c3Ivc2hhcmU6L3Vzci9zaGFyZTovdXNyL2xvY2FsL3NoYXJlClNURUFN VklERU9UT0tFTj0xOTA3CjMyZjVoMjkwZzUzMDQ3Z3Y1MDM0bmJ2dDkyM2IKClRFWFRET01BSU49 c3RlYW0KRElTUExBWT06MApYREdfUlVOVElNRV9ESVI9L3J1bi91c2VyLzEwMDAKU1RFQU1fRlJB TUVfRk9SQ0VfQ0xPU0U9MQpYREdfQ1VSUkVOVF9ERVNLVE9QPUtERQpOT19BVF9CUklER0U9MQpU RVhURE9NQUlORElSPS91c3Ivc2hhcmUvbG9jYWxlClhBVVRIT1JJVFk9L3RtcC94YXV0aC0xMDAw LV8wCl89L2hvbWUvdXNlci8ubG9jYWwvc2hhcmUvU3RlYW0vU3RlYW1BcHBzL2NvbW1vbi9Db3Vu dGVyLVN0cmlrZSBHbG9iYWwgT2ZmZW5zaXZlL2NzZ29fbGludXgK