It seems that by switching the false in FramebufferQPainterBackend::needsFullRepaint() const to true fixes this issue. not sure if it's false for performance reasons... but the one for the wayland backend seems to set needsFullRepaint to true... Reproducible: Always
Created attachment 95912 [details] Photo of the drawing artifacts with fbdev
For this I attempted to create https://git.reviewboard.kde.org/r/126254/
I think we've two bugs here: 1. the old mousecursor area isn't marked damaged at all? 2. The old geometry is repainted insufficiently or not at all. What happens if you move the window to the down-right? Does it make a difference how fast you move the window? Do you get artifacts when closing/minimizing windows (with every animation DISabled)?
Moving the window to the bottom right hand corner does bring up the semi-transparent window resize thing. anything under it does seem to refresh I can move the window slowly and fast, I get more artifacts moving it slow, then moving it fast. It doesn't seem closing the window gives any artifacts
(In reply to bluescreen_avenger from comment #4) > Moving the window to the bottom right hand corner does bring up the > semi-transparent window resize thing. No, I meant whether you get similar artifacts but on the top-left of the window =)
Moving the window towards the bottom of the screen does not cause artefacts, interestingly enough if I move it up it leaves artefacts, then I move it down, it repaints over the remnants... ...I think I might want to change my answer about closing windows... I do get an artefact
(In reply to bluescreen_avenger from comment #6) > Moving the window towards the bottom of the screen does not cause artefacts, Smells like an off-by-one error or related to the titlebar ./. the border size. What about the left edge (when moving windows rightwards)? > interestingly enough if I move it up it leaves artefacts, then I move it > down, it repaints over the remnants... Clearing them or leaving them?
It leaves the artefacts moving the windows up-left it clears them when moving them down-right I'm also realizing some glitches that happen when I hover over some wayland applications, such as wiggly, (it does change on over), It is in the same direction... about to attach a screenshot
Created attachment 95941 [details] drawing glitch also goes within applications that are not moved (qt wiggly test)
Argh... Now I'm realizing it affects the qpainter backend, not just on the Framebuffer, but on the Wayland and X11 backends too
Created attachment 95950 [details] the drawing glitches affecting qpainter in the wayland backend This only effects when the qpainter render is being used, for the wayland (and x11 backend) It seems qpainter also has a weird transparency issue in the xterm text going through the nested window... It does not affect the opengl backend
beautiful :-) But actually I'm glad that it's a generic issue and not just on DRM
*** Bug 364720 has been marked as a duplicate of this bug. ***
I started investigating the bug, and there are in fact multiple: the cursor does not get repainted when changed, the new cursor area is not considered during rendering, the damage on a window clips away the repaint of the old cursor, in non overlapped areas (background) the cursor is not repainted. Overall shows that QPainter compositor was a rather quickly written and hardly tested code base.
Found the main problems and created: * https://phabricator.kde.org/D2023 * https://phabricator.kde.org/D2024 * https://phabricator.kde.org/D2025 Now going to try to auto-test this for the virtual backend.
Git commit 736d99fc6a8e0a1b09f34de6da02a0fbb83e79c3 by Martin Gräßlin. Committed on 28/06/2016 at 10:40. Pushed by graesslin into branch 'Plasma/5.7'. Properly trigger repaint for sofware cursor Summary: When the cursor changes the old and the new cursor geometry needs to be repainted. Also when the cursor image changes a repaint of old and new geometry is needed. To support this the current cursor geometry is tracked instead of just the cursor position. From the cursor position it's not possible to get to the cursor geometry once the cursor image or hotspot changes, thus the complete geometry needs tracking. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2023 M +5 -6 platform.cpp M +1 -1 platform.h http://commits.kde.org/kwin/736d99fc6a8e0a1b09f34de6da02a0fbb83e79c3
Git commit feadcea6cea7b74acf4896c85dcb7d577615ff42 by Martin Gräßlin. Committed on 29/06/2016 at 06:48. Pushed by graesslin into branch 'Plasma/5.7'. [platforms] Call setSoftWareCursor in init instead of ctor Summary: Platform::setSoftWareCursor creates connections to the Cursor in order to trigger repaints whenever the cursor position changes. The Cursor is created before Platform::init is called, but after the Platform is created. Thus the call needs to happen in init, otherwise the cursor is not rendered correctly. FIXED-IN: 5.7.0 Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2025 M +1 -1 plugins/platforms/fbdev/fb_backend.cpp M +1 -1 plugins/platforms/virtual/virtual_backend.cpp http://commits.kde.org/kwin/feadcea6cea7b74acf4896c85dcb7d577615ff42
Git commit fd19db0fbeae321d241c90faec4ed100c2c7037b by Martin Gräßlin. Committed on 29/06/2016 at 06:47. Pushed by graesslin into branch 'Plasma/5.7'. Properly clip the damage region and windows in SceneQPainter Summary: On the framebuffer backend the software rendered cursor was creating rendering artifacts due to incorrect clipping. This change ensures that in a single screen setup the clipping is performed correctly. For multi screen a similar change might be required, but we currently don't have any a way to test that as framebuffer only supports one screen and other (visual) platforms don't support the software cursor. Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2024 M +3 -4 scene_qpainter.cpp http://commits.kde.org/kwin/fd19db0fbeae321d241c90faec4ed100c2c7037b
This issue should be fixed now with the commits above. And in order to ensure that it never happens again: https://phabricator.kde.org/D2046