Bug 261069

how deep is the freeze? can you still suspend compositing (shift+alt+f12)?
is it maybe related to a specific effect (like "blur")?

(In reply to comment #1)
> how deep is the freeze? 

Begins with small freezes, of couple of seconds, then deeper freezes of many seconds.

> can you still suspend compositing (shift+alt+f12)?

During the freeze it is unresponsive but afterwords yes. When a deep freeze happens the composite is automatically suspended.

> is it maybe related to a specific effect (like "blur")?

I'd have to try it out. I downgrade meanwhile because I needed to work. I'll upgrade later to test that out. Please let me know if there's anything else you'd like me to check at that time, as I'll probably downgrade again.

this is probably nvidias PixmapCache re-allocating memory
Check whether it remains with "nvidia-settings -a InitialPixmapPlacement=0" (actually anything from [0,4] but "2" is fine, be aware that this might have performance or visual impacts, eg. "0" blinds titlebars and if you use the xrender backend, "0" is actually horribly slow)

please try settings from comment#3

(In reply to comment #3)
> this is probably nvidias PixmapCache re-allocating memory
> Check whether it remains with "nvidia-settings -a InitialPixmapPlacement=0"
> (actually anything from [0,4] but "2" is fine, be aware that this might have
> performance or visual impacts, eg. "0" blinds titlebars and if you use the
> xrender backend, "0" is actually horribly slow)

Doesn't seem to freeze with value 0
Does freeze with value 2

Disabling/Enabling Blur doesn't seem to make a difference.

(In reply to comment #5)
> (In reply to comment #3)
> > this is probably nvidias PixmapCache re-allocating memory
> > Check whether it remains with "nvidia-settings -a InitialPixmapPlacement=0"
> > (actually anything from [0,4] but "2" is fine, be aware that this might have
> > performance or visual impacts, eg. "0" blinds titlebars and if you use the
> > xrender backend, "0" is actually horribly slow)
> 
> Doesn't seem to freeze with value 0
> Does freeze with value 2
> 
> Disabling/Enabling Blur doesn't seem to make a difference.

Also yes with value 0 effects to have poor performance and some visual problems, even thought I am using OpenGL.

probably not much we can do about it in that case. Setting to "driver bug"

you can flush the cache every now and then by calling "nvidia-settings -a
PixmapCache=0; nvidia-settings -a PixmapCache=1", what should prevent the
"occasional" hangs (but causes "explicit" ones) - also check "nvidia-settings
-q PixmapCacheRoundSizeKB" - the default is 1024. The bigger the value is, the
less such hangs should occur, but the longer they'll likely take.

Also try to use the "only titlebar" decoration mode as offered by at least
oxygen & bespin (for oxygen that means to set "no border" and NOT use the deco
attached shadows)

Also I always wanted to test whether this might be related to KDEs shared
memory usage for icons ('Option "AllowSHMPixmaps" "true"' in the device section
of /etc/X11/xorg.conf - it's by default off and nvidia says is prevents
internal optimizations...)

(In reply to comment #8)
> you can flush the cache every now and then by calling "nvidia-settings -a
> PixmapCache=0; nvidia-settings -a PixmapCache=1", what should prevent the
> "occasional" hangs (but causes "explicit" ones) - also check "nvidia-settings
> -q PixmapCacheRoundSizeKB" - the default is 1024. The bigger the value is, the
> less such hangs should occur, but the longer they'll likely take.

The hangs are not occasional. They are constant. It's more like the unfreezes are occasional.

> Also try to use the "only titlebar" decoration mode as offered by at least
> oxygen & bespin (for oxygen that means to set "no border" and NOT use the deco
> attached shadows)

If these are just workarounds to minimise the problem so I can use the desktop, it doesn't really matter much for me. I'll be using LXDE for now as KDE 4.6 is not very usable at the moment (mainly nvidia drivers related crashes). However if I misunderstood and you think trying these might help diagnose/fix the problem let me know and I'll give it a shot. I simply can't spend much time playing with my system these days, so I've got to minimize experiments to the essential.

 

> Also I always wanted to test whether this might be related to KDEs shared
> memory usage for icons ('Option "AllowSHMPixmaps" "true"' in the device section
> of /etc/X11/xorg.conf - it's by default off and nvidia says is prevents
> internal optimizations...)

I tried this, I hope. OpenSUSE 11.3 uses auto-configuration so there's no such file. I edited /etc/X11/xorg.conf.d/50-device.conf to read:

Section "Device"
  Identifier "Default Device"

  #Driver "radeon"

  ## Required magic for radeon/radeonhd drivers; output name
  ## (here: "DVI-0") can be figured out via 'xrandr -q'
  #Option "monitor-DVI-0" "Default Monitor"

  Option "AllowSHMPixmaps" "true"
EndSection


But I am not sure if this works. I noticed no difference. If anything the freeze was harder.

Still present after the new update to 260.19.29 (OpenSUSE RPMs)

Sorry, wanted to reply earlier.

a) No, allowing SHM pixmaps has no effect (tested myself)
b) maybe "occasional" was an improper term - let's say "random". Did you however try to flush the cache?
c) not using decoration borders (as well as the oxygen-deco internal shadows) will considerably shrink the size of the temp. ARGB pixmap allocated to render the decoration offscreen, what /might/ prevent the buffer stressing

Sorry... I just noticed what is causing the freeze. Should have realised this before. 

The problem is actually changing windows (Alt+Tab) with the Flip Cover effect. Other effects work fine. 

J.A.

(In reply to comment #11)
> Sorry, wanted to reply earlier.
> 
> a) No, allowing SHM pixmaps has no effect (tested myself)
> b) maybe "occasional" was an improper term - let's say "random". Did you
> however try to flush the cache?
> c) not using decoration borders (as well as the oxygen-deco internal shadows)
> will considerably shrink the size of the temp. ARGB pixmap allocated to render
> the decoration offscreen, what /might/ prevent the buffer stressing

(In reply to comment #12)
> The problem is actually changing windows (Alt+Tab) with the Flip Cover effect.
> Other effects work fine. 

errr... sorry, but:
"Flip swicth" (Vista-a-like) OR "Cover Switch" (Mac-a-like) ;-)

- Do you use "accurate" texture scaling?
- Does setting "smooth" fix it?

(In reply to comment #13)
> (In reply to comment #12)
> > The problem is actually changing windows (Alt+Tab) with the Flip Cover effect.
> > Other effects work fine. 
> 
> errr... sorry, but:
> "Flip swicth" (Vista-a-like) OR "Cover Switch" (Mac-a-like) ;-)

Opss Flip switch!

> - Do you use "accurate" texture scaling?
> - Does setting "smooth" fix it?

I had smooth on (the one in the middle, set by default)

Can you try using the coverswitch effect instead and check whether the same issue occurs?

(In reply to comment #15)
> Can you try using the coverswitch effect instead and check whether the same
> issue occurs?

I tried them all, including cover switch. Only flip switch causes this.

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