[Solved] Steam windows still drawing when hidden

stqn · 2014-05-22 14:00:04

I just tried killing compton then running a couple 3D games and playing videos with different players, but things do not show up on different Xfce workspaces (I’m not sure if my players use VDPAU or not).

However, the Flash game “Neo Scavenger” *does* show up on black pixels of other workspaces (whether compton is running or not) and also on the semi transparent part of those broken Gtk3 apps without window borders (only if compton is not running). I’ll just blame the Gnome devs for that last one .

PReP · 2014-05-22 15:02:58

Oh, thanks for investigating, but i think that is another - albeit similar - issue, like hardware flash had before, pixels travling to black areas only.

This issue here is worse since the whole screen of an application, game, video stays on top of everything on the other desktops when switching,
i can for instance neither see my full screen terminal on desktop 3, or firefox on desktop 2, if having a video open in smplayer on desktop 4,
neither in VDPAU or gl - until it is closed down. It seems like some sort of redraw/"cleaning" issue, where the current graphical application does not "take away" it's graphics.

gshearer · 2014-05-22 15:44:35

Someone made the comment earlier in this thread that the window manager (in my case, Awesome) may have a role to play in this. I disagree. Here's why:

I have many other computers of various hardware, all configured identically (I use the same script to build all of my arch workstations). Only systems with nvidia GPU's have this issue. My intel-video systems work just fine, as does my ATI system.

This problem was introduced back when nvidia made that big update to the driver and phoronix (and others) made a big deal about how much it changed. (Sorry I can't recall what version specifically, but it's been months ago at this point).

PReP · 2014-05-22 23:56:35

Yeah i use openbox and would like to keep using openbox for as long as it is possible.

I gave in just now and tried installing compton: https://wiki.archlinux.org/index.php/Compton

I went for compton-git from aur, and disabled as many shadow/transparency/stuff as i could.

And it seems to work now, ateast tested with smplayer (GL output) and Rogue Legacy (SDL2 game) which had issues before.

Did not need a compositor before, have not used any at all until now, so this is a workaround for the real problem
- but at least now it seems to be issue-free until whatever issue gets resolved. bah.

(or perhaps we will have wayland being default by then and the issue is no more : p )

gshearer · 2014-06-03 14:41:26

Just upgraded to nvidia 337.25-1 this morning. NO CHANGE. Grrrrr.

eigengrau · 2014-06-08 09:54:51

Yea, this is really annoying. Using a compositor is not really a viable workaround, with the resulting tearing in video and all. Has anyone taken this to the Nvidia “butracker“ (aka their Devtalk forums)? I’ve searched for older threads there, since the problem now has been around for over 4 months apparently, but couldn’t find anything.

Btw. this issue is much too fanned over various places. Here’s an overview of the threads that I could find.
https://bbs.archlinux.org/viewtopic.php?id=177462
https://bbs.archlinux.org/viewtopic.php?id=177476
https://bbs.archlinux.org/viewtopic.php?pid=1370960
https://bbs.archlinux.org/viewtopic.php?pid=1371241

eigengrau · 2014-06-08 10:00:54

Also might the original poster consider removing the “solved” tag?

eigengrau · 2014-06-08 10:27:37

I’ve opened a thread on the NVIDIA forums, here:

https://devtalk.nvidia.com/default/topi … lications/

I’ve also sent the output of the NVIDIA debug tool to linux-bugs@nvidia.com, and I would advise that others to do the same to increase the chances that the bug may finally be fixed.

Not holding my breath, though.

Last edited by eigengrau (2014-06-08 10:28:19)

stqn · 2014-06-08 10:42:52

eigengrau wrote:

Using a compositor is not really a viable workaround, with the resulting tearing in video and all.

The only reason I installed Compton is to *remove* tearing. (You have to give it the good options for that.)

eigengrau · 2014-06-08 10:59:59

stqn wrote:

eigengrau wrote:
Using a compositor is not really a viable workaround, with the resulting tearing in video and all.
The only reason I installed Compton is to *remove* tearing. (You have to give it the good options for that.)

Thanks, I’ll look into compton. I recall reading once that it was better in that regard; I’ve only tried the workaround using xcompmgr, but the video tearing was insufferable. Any pointers on the appropriate compton options? The compton entry in the wiki does not seem to say anything about tearing.

Otherwise this might be an occasion for me to give Nouveau another spin and see if it’s stable now with the GK106.

stqn · 2014-06-08 13:47:05

eigengrau wrote:

Any pointers on the appropriate compton options? The compton entry in the wiki does not seem to say anything about tearing.

Here’s what I’m using with my GTX 660 / nvidia blob / Xfce:

compton -c -f -o 1.0 -I 0.1 -O 0.1 -C -i 0.95 -z --vsync opengl-swc --paint-on-overlay --backend glx --shadow-exclude "! name~=''" -b --use-ewmh-active-win --glx-no-stencil

The important parts as far as tearing is concerned are: --vsync opengl-swc --backend glx (I think that’s it).
But there are other options in case it doesn’t work as you wish.

eigengrau · 2014-06-08 15:00:32

Thanks! I’ve played around with various possible --vsync settings on the GLX backend. Overall, the tearing problems are less severe in video output, though still noticeable. But it might be a good workaround for some. Though, with the GLX compositor enabled, the windows are rather jerky and unresponsive when dragged, and it seems I am now getting the issues with stale buffers and artifacts while scrolling that were reported in other threads.

Leffe · 2014-06-24 20:43:20

xorg-server 1.15.99.903 has a lot of changes, but after testing I found that they do not fix this bug.

Leffe · 2014-07-05 13:00:56

I tested 331.89 and it fixes the problem. The main line of releases is hopefully updated soon.

* Fixed an interaction problem with xserver 1.15 that occasionally caused OpenGL applications to continue rendering when they are minimized or unmapped.

PReP · 2014-08-11 23:28:25

Yeah this is totally resolved as of a few days ago here, on "main" and not testing-repo.
I am totally happy to let go off a compositor and run "clean" again

Arch Linux

#26 2014-05-22 14:00:04

Re: [Solved] Steam windows still drawing when hidden

#27 2014-05-22 15:02:58

Re: [Solved] Steam windows still drawing when hidden

#28 2014-05-22 15:44:35

Re: [Solved] Steam windows still drawing when hidden

#29 2014-05-22 23:56:35

Re: [Solved] Steam windows still drawing when hidden

#30 2014-06-03 14:41:26

Re: [Solved] Steam windows still drawing when hidden

#31 2014-06-08 09:54:51

Re: [Solved] Steam windows still drawing when hidden

#32 2014-06-08 10:00:54

Re: [Solved] Steam windows still drawing when hidden

#33 2014-06-08 10:27:37

Re: [Solved] Steam windows still drawing when hidden

#34 2014-06-08 10:42:52

Re: [Solved] Steam windows still drawing when hidden

#35 2014-06-08 10:59:59

Re: [Solved] Steam windows still drawing when hidden

#36 2014-06-08 13:47:05

Re: [Solved] Steam windows still drawing when hidden

#37 2014-06-08 15:00:32

Re: [Solved] Steam windows still drawing when hidden

#38 2014-06-24 20:43:20

Re: [Solved] Steam windows still drawing when hidden

#39 2014-07-05 13:00:56

Re: [Solved] Steam windows still drawing when hidden

#40 2014-08-11 23:28:25

Re: [Solved] Steam windows still drawing when hidden

Board footer