compton is a glx based compositor, when a window is resized, compton release the previously bound pixmap, and create a new named pixmap and bind that to a texture, and then render the screen with that.
With the amdgpu/radeonsi driver, that sometimes result in garbage content.
You can find more details, screenshot, and recordings here 
BTW, this problem doesn't happen with intel, or proprietary nvidia drivers.
Does https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/21 fix it?
(In reply to Michel Dänzer from comment #2)
> 21 fix it?
I am the one who initially created the problem on the Compton github and this merge request has solved my issue!
Thank you very much for your very quick reaction!
I often had this issue when doing certain window operations while having high CPU load, e.g. when compiling on all available threads.
I tried several times to reproduce, but it seems the provided patch took care of it.
I would like to point out that I have the problem that appears again but this time when a window is opened (this problem only appears for 1/10 of a second, and is especially visible with a transparent terminal).
Created attachment 143070 [details]
The demonstration video of the problem.
(In reply to Arno Dupont from comment #6)
> The demonstration video of the problem.
Which window manager and compositing manager are you using? See e.g. https://github.com/i3/i3/issues/3577 for an i3 bug which causes similar symptoms.
Even if it's not a window manager / toolkit / application issue, it's probably not exactly the same cause anymore, so it's better if you file your own report.
P.S. some general remarks:
A bug report should only be resolved once the fix has landed in Git master.
A bug report should generally only be resolved or reopened by the submitter or a developer.
Okay! I will check if the problem does not come from my configuration and create a new bug report if it persists.
Thank you for your work.
Thanks for testing https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/21 . I added an optimization on top of the fixes, please re-test to make sure that doesn't re-introduce the problem.
I have tried the new commits and the problem of garbage does not occur.
Nevertheless, during my tests, I wanted to check (by coincidence) if the resizing performance had improved or not. That's where a crash happened. After ~one minute of intensive window resizing, my PC starts to lag and after some more resize freezes completely. I managed to reproduce it with your new commits with the one who initially solved the garbage problem. I also tried with the git master version and this crash is not there.
Haven't had any crashes (or other issues) with the old patch so far, trying the new one now.
I also experienced this kind of visual corruption not just inside Xorg sessions with Compton GLX compositing, but also with xwayland windows inside a KDE Plasma Wayland session. Just like Arno described, usually when starting applications, e.g. Firefox. It was way worse than with a native Xorg session.
(In reply to Arno Dupont from comment #10)
> After ~one minute of intensive window resizing, my PC starts to lag and
> after some more resize freezes completely. I managed to reproduce it with
> your new commits with the one who initially solved the garbage problem.
Not sure how to parse the latter sentence, but I assume you mean this new problem only occurs with the last commit adding the optimization. Otherwise please clarify.
(In reply to tempel.julian from comment #11)
> I also experienced this kind of visual corruption not just inside Xorg
> sessions with Compton GLX compositing, but also with xwayland windows inside
> a KDE Plasma Wayland session.
That can't possibly be the same issue, so it would need to be tracked separately. If it also happens with GNOME on Wayland, I'd file an issue against Xwayland, otherwise against kwin.
(In reply to Michel Dänzer from comment #12)
> Not sure how to parse the latter sentence, but I assume you mean this new
> problem only occurs with the last commit adding the optimization. Otherwise
> please clarify.
I meant that this crash occurs with the first commit (47ae9034) and the last ones (with or without optimizations).
I can also provoke the Xorg to become laggy after some time of intensively resizing the Firefox window (OGL enabled via about:config), I managed to do this two times in a row with the PR patched into xf86-video-amdgpu-git. Without the PR, it didn't crash so far.
Edit: Sorry, I should have rechecked after reformatting my reply. It didn't crash so far, but I needed to restart to restore proper Xorg performance after intensive resizing.
Ah yes, the first patch was leaking GBM BOs. https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/21 updated again, please re-test.
That sounds good! I didn't manage to reproduce the crash with these last commits.
Me neither, looking good so far.
As a sidenote: I also just realized how easily I can trick myself by accidentally installing a package from Pamac cache instead of the freshly created build in the PKGBUILD dir, which Pamac apparently ignored because the patch didn't affect the build number. My oh my, I suppose I almost reported something wrong because of this... :p
All merged, thanks for the report and testing!
While I haven't seen this corruption anymore when doing certain window operations, it occasionally very briefly still occurs when starting 3D applications (Xorg session). I suppose I can't provide more details, as it really seems to be totally random if it occurs, and too short to capture it somehow.