https://bugs.kde.org/show_bug.cgi?id=316734
--- Comment #29 from David Edmundson <k...@davidedmundson.co.uk> --- >Could the issue described in comment 6 be worked around by blocking the >suspend util two (or maybe even three) frames of the lockscreen have been >rendered? That's exactly what it does. Based on the new software rendering test, what I suspect happens is kscreenlocker is fullscreen and kwin is showing the kscreenlocker window. We have seen in the past OpenGL clients when creating a new buffer have leaked contents representing an old backbuffer. We could be in that situation if we're processing screen removal and additons which kscreenlocker will treat as a new window. We typically guard that with sync requests, but because the screenlocker is an override-redirect, that could potentially skipped. We would need some way to prove that - and if so the fix, somewhat counter intuitively, would be to slow down the screenlocker_greet mapping after creation. -- You are receiving this mail because: You are watching all bug changes.
