[background image]: appears to move up and left when opening fullscreen window

[star-buck]

recorded in Plasma 5.4.1 on Manjaro:
https://www.dropbox.com/s/0otx5n1z9gm4lbw/background-lifted-up-and-left.mkv?dl=0

[mck182]

It's not the wallpaper moving actually, it's the Dolphin window getting initially filled with whatever graphic content is beneath it. Basically it can be said that it is a graphics corruption. I'm not an expert in this area though, so cannot suggest any solutions to that. Will require @mgraesslin's input.

[star-buck]

makes sense, its not just dolphin, its also other windows like system settings if they open fullscreen.

[mgraesslin]

Big assumption coming: I noticed this problem with the screen locker greeter (it actually mapped the window, but contained the copy of the window, so it looked like unlocked but in fact is locked) and with kwin_wayland on X11 backend. For the latter one I realized my coding mistake and fixed it directly before my vacation: https://quickgit.kde.org/?p=kwin.git&a=commit&h=6326d96c02beba482527b842f8d9d4a5c6657664

Based on that my assumption is that with Qt the more or less same happens: it opens a window with no content. But my investigation didn't find it: the code is fine and correct. So the problem is rather somewhere with Qt's OpenGL usage: the rendering buffer has undefined content and is swapped too early, causing the window to show, sending the sync ack to KWin (telling it "hey I'm done with rendering) and all that mess. Also the problem seems only to happen since Qt started to default all rendering to OpenGL (I have no idea how they got to that's a good idea, but well...).

Long run: Wayland will fix it (of course ;-) ). On Wayland the applications should not get a buffer with a copy of the screen content (that would be a very severe security bug in the OpenGL drivers). And the Wayland protocol makes it much more difficult to submit not finished frames to the compositor. E.g. KWin itself defers any handling on Wayland windows till we get the first properly committed frame.

Short run: given that I started investigating before the vacations i hope to find some time for it to write a small test application to easily demonstrate the problem and figure out what's going wrong and where.

[star-buck]

Is it a certain Qt version that introduces the problem (I think up to recent kcis I didnt notice that behaviour)?
Maybe someone else can help you investigating with regards to the Qt-stack?

[mgraesslin]

Is it a certain Qt version that introduces the problem

The default switched in I think Qt 5.4 which would not fit your observation. Probably there are more components in play for the behavior as the "wrong" buffers are most likely provided by either Mesa or DRM kernel module. Changes there being exposed now seems more likely.

Maybe someone else can help you investigating with regards to the Qt-stack?

That would of course be appreciated. Though I don't have an idea who (we need someone with knowledge about the complete stack and I doubt such a person exists on this world ;-) ). A start could be: our NVIDIA users could try whether they also see the problem.

[star-buck]

seems on an old computer with ati, this is different (but could also be that it is now Plasma 5.5.3)

[mgraesslin]

Plasma version shouldn't matter. It's a Qt bug in cooperation with bugy drivers. So different GPU/driver can behave differently.