Bug 343661

That's the nvidia system?

Is the vlc sink xv, vdpau or gl?

Does/did the repaint happen if you suspend the compositor (SHIFT+Alt+F12)

I more than seldom get stalls in vdpau windows when re/starting the compositor (in KWin 5 as well as 4) - this could eg. also happen for a graphics reset. You'd then have gotten a notification
"Desktop effects were restarted due to a graphics reset"



Another candidate would be bug #343551
In that case

     KWIN_EXPLICIT_SYNC=0 kwin_x11 --replace &

would prevent the fences invocation.

Yes, this is the sli nvidia system.

VLC is set to "auto-video", so I'm not really sure what it's using, but I believe it's gl.

This is the full story:

I started watching a movie with VLC. I got tired and decided to go to bed, but I didn't shutdown/suspend my PC. I just turned off the monitors. Next morning I woke up and decided to finish the movie with having the breakfast. That's when I noticed the problem.

Kwin wasn't drawing the video inside VLC's UI. I was hearing the sound/voices, but I was seeing only a frozen image of the movie. 
If I started resizing VLC's UI, the image would start drawing again, but as soon as I stopped resizing VLC's UI, the video would freeze again.

Also note that compositing was fine, and when I resized VLC's UI I was able to see how kwin was making the UI semi-translucent (I enabled that if KDE's option), so GL, compositing, my nvidia driver all were working fine.

That seems to be xv (vlc has no vdpau sink here at all)

What could happen is either
1) vlc simply doesn't update (unless caused by resizes)
2) vlc does not cause damage events for updates
3) the redirection broke
4) the sloppy texture binding (to the redirection target pixmap) failed

(3) & (4) should "fix" by (NOT "while") resizing the window ("considerably", eg. more than 128px in one direction) - so I assume we can ignore this?

(1) would mean no uncomposited updates either, otherwis (2) becomes the likely candidate.

I'm not sure it's neither 1 or 2, because I haven't noticed that behavior before (read as with KDE4), and this is not the first time I delay the end of a movie for the next day.

Confirmed, it's not a VLC-related bug as this just happened with Chrome too. Here is a video http://youtu.be/Rl5sGaI7ST8

Nobody said anything about vlc ;-)
It's probably related to the xv/overlay stuff.

Since it's updated w/ pure moving, which is not promoted to the client, this is a lack of damage events, either not emitted by the client or not received by kwin (eventhandling) or not translated into a sufficient update or the update doesn't make it into the frontbuffer.

At 7.0 seconds you switch the tab away from the video.
Right before the tab changes, you can see (frame by frame stepping) that the video updates 2 frames (also the tab switch itself causes a damage event + update)

=> KWin in general still does receive and handle damage notifications from this window.

Either it fails on partial damage events (ie. when switching the tabs, the entire window might be tagged dirty - otherwise only the video region), or the client doesn't generate them sufficiently.

Interestingly, the switch back to the video does obviously not cause a damage event.

Assuming that one switch will act like the other, this seems to suggest that the dimension of the event is irrelevant.

Conclusion (so far): the required damage events are not generated.

Video playback seems to be a (the) trigger, yesno? (ever encountered entirely unrelated to video playback?)

As for the dead webview, I've no real idea how to explain that (maybe due to hw accelerated, ie. opengl, rendering?) but do assume it's related to the overlay video.

=> When this happens again, please check the impact of destroying the video (close the tab)

>> Video playback seems to be a (the) trigger, yesno? (ever encountered entirely unrelated to video playback?)

Maybe it is, but I'm not really sure because I always have some YouTube tab open playing in the background. Can't live without music, sorry :D

>> When this happens again, please check the impact of destroying the video (close the tab)

Ok, will do.

>> When this happens again, please check the impact of destroying the video (close the tab)

It happened again! (in Chrome) After closing the video tab, the rest of the browser kept in a buggy state, so the "problematic" tab isn't actually causing any trouble nor is fixing the problem once it gets closed.

Summing up: once the content of a window stops drawing, the only fix is to kill the entire app and open it again.

I also noticed that the bug happens really often with pavucontrol.

(In reply to Alexander Nestorov from comment #8)

> I also noticed that the bug happens really often with pavucontrol.

Ie. "pavucontrol stops updating" or "video freezes after using pavucontrol"?

pavucontrol stops updating. The fastest time I got the bug was just a few minutes after running it. When it bugs, it won't let me move any controls (well, it actuallly does let me move the controls, but I can't see what am I doing because they are not rendered).

Ok, pvucontrol will rather not contain some overlay.

Stupid question: is vlc the gtk frontend?

>>  is vlc the gtk frontend?


What do you mean? If VLC is using GTK?
I have no idea if VLC is using Qt or GTK, but I haven't changed any toolkit settings in VLC, so I assume VLC is using the default.

(In reply to Alexander Nestorov from comment #12)
> I have no idea if VLC is using Qt or GTK, but I haven't changed any toolkit
> settings in VLC, so I assume VLC is using the default.

"pacman -S vlc" would install a Qt4 GUI, yes - so it would NOT be gtk3 NOR xv - or gtk3 AND xv

Let's install pavucontrol ;-)
Any special trigger there? (never used, no PA here)

Ps: did you try
   KWIN_EXPLICIT_SYNC=0 kwin_x11 --replace &

>> Any special trigger there? (never used, no PA here)

Nope. Just run pavucontrol and leave it open (try not minimizing it, just hide it behind other windows). Do normal stuff. Maybe play a video or a few songs. Get back to pavuncontrol and check if you can control it.

(Btw, you'll notice  that pavucontrol has a huge memory leak)

Any news on this one? It's really annoying to have coding/debug session in a <favorite editor>/terminal and suddenly find out kwin won't render it's content anymore and the only way to continue the work is to close that app and open it again.

So far not been reproducible, sorry :-(

It should be really sufficient to suspend/restart the compositor (SHIFT+Alt+F12)
If it's not, it's on the clients side for *dead* sure.

I have noticed that, except pavucontrol, this bug is really slow to reproduce (about 30-40 hours without closing the app before seeing the bug).
What do you mean by client side?

The client (eg. pavucontrol) simply stops causing damage events (rather than KWin not receiving/handling them)

=> Does toggling compositing off/on have impact or does it not?

Hmmm.... I'm not really sure what are the chances that, suddenly, VLC, Chrome, pavucontrol and Terminology got broken by the same bug, instead of kwin doing funny things.

I'll try the toggling thing and let you know.

Yup, I got the bug again. Toggling compositing fixes it, so it's something in kwin/plasma/<something in kde> for sure.

(In reply to Alexander Nestorov from comment #21)
> in kwin/plasma/<something in kde> for sure.
"nope" ;-)

Not "the client for sure" does not imply "something for sure" - we're simply back at "we can't point the cause" :-(

What really puzzles me is that the video you made clearly shows that the browser AND the video inside indeed still *do* update, namely when switching tabs.

Once again, did you try:
   KWIN_EXPLICIT_SYNC=0 kwin_x11 --replace &

Another wild shot would be to deactivate blur & contrast effects and see whether it still happens (but i'm not really sure how those should act differently on video playback & tab switching)

Should I run KWIN_EXPLICIT_SYNC=0 kwin_x11 --replace & now and wait for the bug or should I run it when the bug happens?

Run it now and wait whether the bug still occurs (or force pavucontrol on it ;-)

It's unfortunately only a negative test (ie. if the bug still occurs, that's not it - otherwise it's safe to say it's related if the problem remains absent "for a long time"™)

I ran that command yesterday and opened right away pavucontrol. Now, more than 24h later, pavucontrol is still working fine. I think we can call that a kwin bug, right?

Stunningly it's been the very first thing I suggested ... :-P

I *may* be a kwin bug =)
The nvidia driver is known to have a bug in at least the legacy variant =)
(It's afaiu also the only driver that currently supports this itw.)

Can you try this patch https://bugsfiles.kde.org/attachment.cgi?id=91353 for a start.

Ok, I can try to apply this, but I have quite a few questions. First of all, to which part of KDE does that patch applies?  Second, to what version does that patch applies? And third, is there a guide for applying patches, compiling KDE, etc etc etc that I could follow?

(In reply to Alexander Nestorov from comment #27)
> to which part of KDE does that patch applies?
kwin
> Second, to what version does that patch applies?
5.2 (yours)

> And third, is there a guide for applying patches,
> compiling KDE, etc etc etc that I could follow?

You don't need to "compile KDE", kwin should be sufficient (though the master branch will likely require kwindowsystem.git master as well)

git clone git://anongit.kde.org/kwin.git
cd kwin
git checkout Plasma/5.2
patch -p1 < /path/to/the/patch.diff
mkdir build
cd build
ccmake ../ # no typo, ccmake is the curses variant, ie. you can alter the paths etc. via a "gui"
# adjust options, notably the prefix, likely to /usr
make
sudo make install # profit!

Alternatively keep the variable exported (as workaround) and wait for 5.2.2 (Thu 2015-03-19)
There's however no guarantee that the patch will fix *this* bug as well :-(

Bad news, I'm testing 5.2.2 and the bug is still present.

This happens to me all day long, in every application, since upgrading to Kubuntu 15.04. It happens mainly in Chrome but occasionally in other apps, especially apps running in Wine. I've also triggered it in Sublime Text 3 and a few other random apps.

I can still interact with the window, I just don't see any repaints. I can force a repaint by minimizing and unminimizing the window. While browsing other bug reports I came across "kwin_x11 --replace" which also fixes it (much to my relief, I'm about to break the damn keyboard over here).

I have no idea what triggers it... I have an Nvidia card (using the proprietary drivers), OpenGL 2 + GLX compositor.

I will try disabling the compositor next time it happens.

please check & try comment #23

I'm having an issue which I *think* is symptomatic of the same bug - although I'm on Intel, not Nvidia. When I alt+tab between windows, sometimes the content stops refreshing. Input is definitely being sent to the windows that this happens to. If I alt+tab back and forth a few times, I can get the window to "unstick" and behave normally again.

Running the command suggested in comment #23 appears to also resolve the behavior I'm seeing, which is why I suspect it to be the same issue under the hood.

Below is the output kwin_x11 spit out when I ran it with --replace.

OpenGL vendor string:                   Intel Open Source Technology Center
OpenGL renderer string:                 Mesa DRI Intel(R) Haswell Mobile 
OpenGL version string:                  3.0 Mesa 11.1.1
OpenGL shading language version string: 1.30
Driver:                                 Intel
GPU class:                              Haswell
OpenGL version:                         3.0
GLSL version:                           1.30
Mesa version:                           11.1.1
X server version:                       1.18
Linux kernel version:                   4.3.3
Requires strict binding:                yes
GLSL shaders:                           yes
Texture NPOT support:                   yes
Virtual Machine:                        no

I'm running kwin 5.5.3 with kwindowsystem 5.18.0 (latest in Arch).

Can you please attach the output of "glxinfo" (assuming you're using the glx backend)?

Created attachment 96789 [details]
glxinfo output on Haswell gpu

No support for GL_EXT_x11_sync_object, so this is a red herring. The kwin restart resolved the freeze implicitly, but KWIN_EXPLICIT_SYNC=0 has no effect at all.

PS, please attach the output of "qdbus org.kde.KWin /KWin supportInformation" to check for other possible causes.

Created attachment 96860 [details]
Kwin support output

 Here's the dbus output as requested. I can also confirm that running `kwin_x11 --replace` without the environment variable works for me, so it's just the act of replacing kwin that seems to fix it. Oddly, logging out or restarting the machine tends to leave me with a kwin that freezes on alt-tab again. It's the actual replacement step that fixes it (although it's possible I haven't left kwin running long enough after a --replace for the bug to manifest again)

Stupid question, because of the apparent trigger: does it also happen if you use the cover- or flipswitch effect as tabbox (kcmshell5 kwintabbox)

It doesn't always trigger consistently, but I'll try changing my switcher to see if that helps when it starts freezing.

Arch also just pushed out 5.5.4, so maybe if I'm lucky it just won't break anymore

the good/bad news is that I'm seeing this still today with 5.5.4. I'm switching to the coverswitch tabbox and I'll let you know if I'm still seeing it over the next couple days

That was quick - after switching to cover switch, my browser window froze as the kcmshell5 window was fading out, leaving a semi-transparent kcmshell window over the browser window. As always, switching to another window and back unfroze (I suspect the "switching unfreezes" is actually something to do with window visibility, rather than focus?)

I can report I get this with annoying regularilty, Kubuntu 15.10, NVidia (HP Envy laptop).  It seems to have occurred since 15.04:  a window simply stops being refreshed unless it is resized.  

The problem is attached to the window, not the application: using Chrome or Firefox, I can drag a tab out into its own window and that new window updates fine, I can even drag all the tabs one by one onto the new one until the old window is empty (and thus destroys). (Until it occurs again on the new window, sigh!).    Not all applications can be recovered this way . It's particularly annoying with virtual machines where the only way to get a new window is to shut the VM down (or at least, sleep it).

I have not found any pattern in when a window decides to stop updating. 

(A second thing that may or may not be related, but I'm mentioning it for completeness:  if I plug in a second monitor , then I also get a lot of tearing or incomplete paints. I first noticed this on a image view program - as each new image was displayed it would be blurry or leave some of the previous image in view. It's not just that program, seen it with Virtualbox as well. However in this case, wiggling the mouse forces the window to paint correctly, even if the mouse doesn't travel over the corrupt area;  and I've only ever seen it happen on the external monitor).

I'm very interested to hear that kwin_x11 --replace might solve/reset the problem, I'll definitely try this next time.
I notice bug is 12 months old, about 4 people are reporting it, yet it still has status "unconfirmed". What does it take to confirm a bug then? <g>

The confirmation flag is rather insignificant, sometimes devs set it when they can reproduce the problem.

To confirm this is really/likely this bug, run
    KWIN_EXPLICIT_SYNC=0 kwin_x11 --replace &
and see whether it ever occurs with this variable exported.

It might take a while but I'll experiment. I'll wait for repaint issue to reoccur first and see what Shlft-Alt-F12 does, then of course will have to wait again, possibly for several weeks, to be sure it is gone away with the SYNC setting. I'm guessing 

Thanks for your attention to this bug.  So often I look up annoying behaviour and find that a bug is logged but seems to be abandoned.  I'm a bit motivated to get some of these bugs squashed -  I love KDE/Kubuntu but am seriously having to consider whether to switch OSes (at worst, to Windows) to get stability on my work machine.

> I'm guessing 
Oops, meant:  I'm guessing there might be a performance penalty with this setting?

No, the feature coordinates OpenGL and X11 drawing, ie. reduce tearing/flicker aso.
I could assume there's a deadlock with some clients where kwin sets a fence, the client is supposed to update, the client uses OpenGL and that now accidentally thinks it needs to wait for the fence kwin set. But that's really just a wild guess on what might happen.

I've just created   ~/.config/plasma-workspace/env/kwin.sh with that setting as noted on some similar bugs. It will be few days before I am sure it fixes anything!

on next login, ensure the file got sourced, in konsole run
   echo $KWIN_EXPLICIT_SYNC
should print "0"

Sage advice, Thomas.  This is odd. Did not survive a reboot.  It runs the script but doesn't set the setting.  This might be getting a bit off topic, but looks like it is time to further debug kde.  I hope this formats ok and makes sense.

kwin.sh contains (extra logging to prove it ran and did its job, or not, as is the case)
  #!/bin/sh
  echo kwin.sh was run! >>/var/log/kde_debug_temp.log
  echo In script Before KWIN_EXPLICIT_SYNC is: $KWIN_EXPLICIT_SYNC  >>/var/log/kde_debug_temp.log
  export KWIN_EXPLICIT_SYNC=0
  echo In script After KWIN_EXPLICIT_SYNC is: $KWIN_EXPLICIT_SYNC  >>/var/log/kde_debug_temp.log

If, from bash prompt, I run /home/walter/.config/plasma-workspace/env/kwin.sh   then as expected nothing is set;  if I source /home/walter/.config/plasma-workspace/env/kwin.sh  then KWIN_EXPLICIT_SYNC is set afterwars as expected. If I create newtest.sh  containing only  the line "  .  kwin.sh "  then KWIN_EXPLICIT_SYNC is set as expected (well ,for the duration of the script anyway since it isn't itself sourced).

However if I modify startkde so that it contains logging
echo In startkde Before KWIN_EXPLICIT_SYNC is: $KWIN_EXPLICIT_SYNC  >>/var/log/kde_debug_temp.log
for prefix in `echo $scriptpath`; do
  for file in "$prefix"/env/*.sh; do
    (test -r "$file" && . "$file") || :
  done
done
echo In startkde After KWIN_EXPLICIT_SYNC is: $KWIN_EXPLICIT_SYNC  >>/var/log/kde_debug_temp.log

Now reboot and look at the log file , it shows:
  In startkde Before KWIN_EXPLICIT_SYNC is:                                                                                                                                                                        
  In script Before KWIN_EXPLICIT_SYNC is:                                                                                                                                                                          
  In script After KWIN_EXPLICIT_SYNC is: 0                                                                                                                                                                         
  In startkde After KWIN_EXPLICIT_SYNC is:       

So my script is DEFINITELY executing, it is DEFINITELY setting the env var, but that extra indirection in startkde -      (test -r "$file" && . "$file")     -  is enough to stop the setting from taking.  So how the***^&#%#$($#%!  was this ever supposed to work???

[ This is exactly your advice from https://bugs.kde.org/show_bug.cgi?id=348753  -  has something changed in Ubuntu 15.10? ]

You're running a broken startkde version, see
https://quickgit.kde.org/?p=plasma-workspace.git&a=commitdiff&h=f869daca8244131f6b452e2c15b4dee5903ff768

for the fix, resp. bug #352491 for the full story.

So in an attempt to  work around one bug I discover another bug, a commit that frankly should never have hit trunk.  Big Sigh!  As I said, "seriously having to consider whether to switch OS" .... oh well, I've applied the patch in the hope that Kubuntu won't distribute another borked version, and hopefully will see both this probably and the dual-monitor repaint/tearing issue go.  Thanks for all your assistance this weekend.

Aside: This doesn't fix the tearing problem on external monitor - not the subject of this bug but in case someone is wondering. Jury still out on the windows-stop-drawing issue obviously - calling that one will take weeks.

You can only sync to one screen - HW limitation (but you can control to which, __GL_SYNC_DISPLAY_DEVICE, nvidia only, needs to be set to the output name as listed by xrandr; see /usr/share/doc/nvidia/README on details)

Also this doesn't defeat tearing per-se, but only one part of the cause chain.

(In reply to Thomas Lübking from comment #53) You can only sync to one screen - HW limitation
Yes, I know, but the tearing started around the same time, after a year or more of no display issues at all, so I wondered if they could be related. It doesn't look like they are, so we can drop discussing it here! Thanks, though.

OK that didn't seem to fix it.   kwin_x11 process definitely has environment variable set:

walter@rukbat:~$ xargs --null --max-args=1 < /proc/`pidof kwin_x11`/environ | grep KWIN
KWIN_EXPLICIT_SYNC=0

This occurred with firefox, had about 3 tabs open, then opened two new tabs (with Ctrl-Click on link) - they 'seemed' to be taking a long time. Then I realised why...
Then it "infected" the next firefox window,  the one I was adding this comment on.
So once occurred - can click on each tab in the firefox window and the TITLE BAR changes (eg to 
"New Tab - Mozilla Firefox" ,  then "Slashdot: News for nerds ... - Mozilla Firefox"  etc) but the client area of the window is not redrawn.  That includes scrollbars, the tab bar itself, menu bar (although menus themselves pop down: probably they are new windows).   I can right-click on tab and select "Move to New Window" which is what I've just done to type this!

Pressing Shift-Alt-F12 twice (to toggle the compositor) repairs the problem and the window starts updating again.

I still haven't tracked down a trigger, but I did wonder about these:
  - I've only ever seen this when external monitor is plugged in.  But that is 90% of the work day..
  - or maybe, I have a Windows 7 VM in VirtualBox, full-screened on my external monitor. Again, that's not uncommon in my work day.
Don't want to get hung up on the dual-monitor thing, but it might explain why this problem isn't more widespread.

Can confirm, that KWIN_EXPLICIT_SYNC doesn't change the behavior.

However, I noticed that it might be a bit driver-dependent. For my GPU (AMD Kaveri), I can use two different KMS drivers: radeon or amdgpu
(mesa driver is in both cases radeonsi, ddx is xf86-video-ati or xf86-video-amdgpu)
When I use amdgpu with vdpau, I see this exact behavior *every* time I open a video with mpv and I see it a lot more often with other windows ("normal" windows without any video output). With xvideo, it does happen, but not always.
When I use radeon I do see the problem, but only occasionally and most of the time with video output (e.g. firefox or mpv, although with the latter I think I've only seen it with xvideo).

I know this problem well since Fedora 20. Windows with frequent updates are the first to freeze (plasmashell with CPU monitor, pavucontrol, Chrome with open meta refresh page or  youtube video). Setting environment variables KWIN_USE_BUFFER_AGE/KWIN_EXPLICIT_SYNC does not help. Shift+Alt+F12 fixes for a while.

Recently found that switching compositor to OpenGL 3.1 / EGL over OpenGL 2.0 / EGL modifies the behaviour on Intel video: the whole desktop freezes after 4-8 days instead of the frequent (daily) window content freezes. I can still interact with the last active window but the screen does not refresh anymore. It's not better at all, just different. This way Shift+Alt+F12 does not help and kwin does not respond on D-Bus.
I know it is not much info, but nobody mentioned yet..

I want to confirm this issue on a Thinkpad T440s (i7-4600U, Intel video)

Plasma 5.5.4
QT 5.5.1
Kubuntu 15.10


I have absolutely no idea where to get debug info from, if someone can tell me commands to execute or dbg pkgs to install, I'm willing to try.

This does seem to start occuring either after a Suspend/Resume and/or Plugging an external monitor.

Also, to confirm, going to EGL in favor of GLX, does not seem to help at all for me... I have to Alt+Shift+F12 to disable effects in order to restore drawing

I haven't seen this problem reoccur for me in the last month. Maybe a software patch has changed behaviour:
Kernel now 4.2.0-35-generic 
plasma-workspace at  4:5.4.2-0ubuntu1.1
nvidia-352  version 352.63-0ubuntu0.15.10.1
(I'm not sure which packages are actually relevant to this).

Other family members with KDE computers haven't ever seen this, by the way, although my wife did have a problem which toggling Alt-Ctrl-F12 fixed for her. Something about the plasma bar getting corrupted? Could have been same issue. Fairly old Toshiba laptop with intel video.

After that last comment, of course the problem reoccurred this evening.  (ha ha ha...)   External monitor not plugged in at moment, although it had been several times since last reboot.

This has been driving me up the wall since I "upgraded" to Plasma 5 over a year ago.  Never happened on KDE 4.

I've seen it affect at least Chromium, VLC, Krita, GZDoom, pico-8, and /very rarely/ Firefox or LilyTerm.  (Firefox is my primary browser; Chromium I basically just use for YouTube.)  It only seems to affect windows using OpenGL — once when it was particularly bad, I turned off OpenGL in Krita for a while, and Krita became immune.

It's definitely per-window.  Moving a busted window will cause it to repaint during the move (because it's translucent, I imagine), then refreeze.  The taskbar's live thumbnails show the correct window contents, but the window itself does not.

It seems to happen more often when my machine's been on for a while, and/or when more apps are trying to use OpenGL, and/or when there are a lot of repaints happening.  Sometimes I go hours or (if I'm lucky) days without seeing it; sometimes it happens every few /minutes/.  It seems to happen more often after a "trigger" like alt-tabbing or closing a Chromium tab, but it also happens spontaneously in the middle of using a single app.

I don't know if it's related, but after enough rounds of toggling the compositor off and back on, the un-composited panel ALSO freezes, and nothing short of restarting kwin will fix it.  It turns a very dark gray when frozen, versus Breeze's usual medium-light gray.

Ha.  Firefox just "froze", right now, while typing this.  No video playing, nothing onscreen but a browser window with a textbox and an idle terminal.  I have Chromium, pico-8, and Krita running, but they're all idle and minimized.

Arch, nvidia blob driver, two monitors.

I've stumbled into an issue very similar to what's described here.

"kwin --replace" crashes for me, so I couldn't test that. However, I tried to run Openbox instead of KWin, and freezes continued. I tried it with both "KDE/Openbox" session, and with "openbox --replace".

I managed to fix this issue by switching compositing from OpenGL 2.0 to OpenGL 3.1 in Desktop Effects.

Can the cause be something else, not kwin?

Running ubuntu 14.04 with nvidia blob and two monitors. (I don't know whether this is relevant or not)

Created attachment 100607 [details]
glxinfo

I didn't mention: KDE 4.11.11 and 4.13.3, depending on the package. Not Plasma 5.

trying to finish an important product and it just freezes on me

trying to complete an important animation

Please don't hijack this old KWin ticket for Krita issues. I suggest to report a new ticket.

This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!

I am hitting this bug. Seems like it happens mostly in windows that are playing videos / media content (radio, videconference, youtube, etc).

Had it both in Firefox and Brave but it is definitely not linked to the as some FF windows work fine while other don't. Also when you click on the window title bar the content refreshes. Restarting compositor solves the problem.

Operating System: KDE neon 5.25
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Kernel Version: 5.15.0-48-generic (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz
Memory: 15.4 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620

*** This bug has been marked as a duplicate of bug 456511 ***

(In reply to Gauthier from comment #74)
> 
> *** This bug has been marked as a duplicate of bug 456511 ***

same here

(In reply to Gauthier from comment #73)
> I am hitting this bug. Seems like it happens mostly in windows that are
> playing videos / media content (radio, videconference, youtube, etc).
> 
> Had it both in Firefox and Brave but it is definitely not linked to the as
> some FF windows work fine while other don't. Also when you click on the
> window title bar the content refreshes. Restarting compositor solves the
> problem.
> 
> Operating System: KDE neon 5.25
> KDE Plasma Version: 5.25.5
> KDE Frameworks Version: 5.98.0
> Qt Version: 5.15.6
> Kernel Version: 5.15.0-48-generic (64-bit)
> Graphics Platform: X11
> Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz
> Memory: 15.4 GiB of RAM
> Graphics Processor: Mesa Intel® UHD Graphics 620

same here