Windows moving becomes slow and urgly after severeral times of xorg modes switch

Bug #770219 reported by Kole de nNix
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Unity
Invalid
Undecided
Unassigned
nvidia-graphics-drivers (Ubuntu)
Confirmed
Undecided
Unassigned
unity (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

After several times of xorg modes switch windows starts moving not smoothly (like refresh rated down to 25 ~ 30 fps), but without tearing. This happens in system with nvidia-current blod driver, compiz sync to vblank - enabled, comiz detect refresh rate - disabled, compiz refresh rate - 60. Also the shadow for focused windows draws as shadow for unfocused windows (When system starts - the shadow for active window is rather wide then for unfocused one - looks great).

Revision history for this message
Kole de nNix (koledennix) wrote :
Revision history for this message
Kole de nNix (koledennix) wrote :

The fact is after reboot of my notebook windows moving become smooth, but shadows not.
Another fact - all that i have described above happens after launching of compiz-fusion icon. I remove all compiz related folders from ~/.config/ and from ~/.gconf/app/ and shadows works well. So the shadows was the issue related with compizfusion icon, that rewrite some compiz settings.

Revision history for this message
Bilal Akhtar (bilalakhtar) wrote :

I guess this is normal. How much RAM does your notebook have? And how much of it is used when you are experiencing this?

Revision history for this message
Kole de nNix (koledennix) wrote :

My notebook has 4 gb of ram and 2.5 gb is used by programs at that moment (Eclipse so fat ). So I think (it can be mistake of course) this issue is not related to ram but to wrong compiz settings gained from compizfusion icon. Yesterday I have delete compiz-fusion icon, witch was saved after upgrading from maverick. After reseting compiz settings all works fine.

As far as I know there is another issue with nvidia blob driver - the xorg memory increases each time modeswitch has taken. (I use external monitor on my work). So after several days of work xorg can use about 250 mb of memory or more. But in the issue I`ve described above xorg has used 100mb and I has more than 1 gb of free ram.

Now my system uses 1,5 gb of ram, xorg uses 111 mb (3 or 4 times the xorg modes was changed) and all works fine.

Thanks.

Revision history for this message
Kole de nNix (koledennix) wrote :

The issue comes again.

16:42:48 up 2 days, 1:16, 3 users, load average: 0.18, 0.13, 0.08
326m 181m 8896 S 4 4.9 108:27.02 Xorg
880m 175m 24m S 5 4.7 107:00.29 compiz

Windows moving very slowly. Switching between windows slow to. This actions takes 60-80 % of cpu in compiz process.

Revision history for this message
Kole de nNix (koledennix) wrote :

Maybe this issue is related to using of tmps for /tmp, /log ? I know that performance can be slow down if size of tmpfs more than half of ram.

Alex Launi (alexlauni)
Changed in unity:
status: New → Invalid
Changed in unity (Ubuntu):
status: New → Invalid
Revision history for this message
Kole de nNix (koledennix) wrote :

Sorry for my question, why this bug was marked as "Invalid" ? Is something wrong with description? Is this issue related to no one else?
I can confirm that issue steel presented and very annoying. I have to shutdown my laptop instead to put it into suspend.
If I can help to solve this problem - please let me know. Thanks.

Changed in nvidia-common (Ubuntu):
status: New → Confirmed
Revision history for this message
John Doe (podcherklife) wrote :

This also affects me. I'm running unity on nvidia gt9600m with 4gb ram so performance shouldn't an issue.

Disabling decoration plugin in compiz settings solves the problem.

Revision history for this message
Kole de nNix (koledennix) wrote :

"Disabling decoration plugin in compiz settings solves the problem." But how to work with windows without borders and close/hide/maximize buttons ?

affects: nvidia-common (Ubuntu) → nvidia-graphics-drivers (Ubuntu)
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I think we fixed this already. Perhaps it was in bug 969101 ?...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.