Opening the dash or alt+tab it is very slow and laggy

[Zed]

opening the dash or alt+tab it is very slow and laggy. It doesn't matter if I'm using blur ore not, or disable effects in compiz setting manager or not.

Looks like problem with Gallium3d drivers.
So needs some tweaks or force uniti2d mode for all old ati card.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: unity 4.24.0-0ubuntu3
ProcVersionSignature: Ubuntu 3.2.0-5.11-generic 3.2.0-rc5
Uname: Linux 3.2.0-5-generic i686
.tmp.unity.support.test.0:

ApportVersion: 1.90-0ubuntu1
Architecture: i386
CompizPlugins: [core,bailer,detection,composite,opengl,decor,compiztoolbox,resize,imgpng,place,regex,unitymtgrabhandles,move,grid,snap,mousepoll,vpswitch,gnomecompat,session,animation,wall,fade,scale,expo,workarounds,ezoom,unityshell]
CompositorRunning: compiz
Date: Sun Dec 18 22:30:38 2011
DistUpgraded: Log time: 2011-12-17 22:56:02.069860
DistroCodename: precise
DistroVariant: ubuntu
EcryptfsInUse: Yes
GraphicsCard:
 ATI Technologies Inc RV350 AS [Radeon 9550] [1002:4153] (prog-if 00 [VGA controller])
   Subsystem: Device [1fd3:4153]
   Subsystem: Device [1fd3:4152]
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha i386 (20111129.1)
Lsusb:
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 003 Device 002: ID 0d8c:0201 C-Media Electronics, Inc. CM6501
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
ProcEnviron:
 PATH=(custom, no user)
 LANG=ru_RU.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-5-generic root=UUID=332d40f9-7e07-4b6e-a990-c7c801f95940 ro quiet splash vt.handoff=7
SourcePackage: unity
UpgradeStatus: Upgraded to precise on 2011-12-17 (0 days ago)
dmi.bios.date: 02/22/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P3.30
dmi.board.name: AM2NF3-VSTA
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP3.30:bd02/22/2010:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnAM2NF3-VSTA:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.
version.compiz: compiz 1:0.9.6+bzr20110929-0ubuntu8
version.libdrm2: libdrm2 2.4.27-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 7.11-0ubuntu4
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.11-0ubuntu4
version.xserver-xorg-core: xserver-xorg-core 2:1.10.4-1ubuntu6
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.0-1ubuntu13
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20110811.g93fc084-0ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.15.901-1ubuntu4
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1

[Alberto Salvia Novella (es20490446e)]

Thanks for you report. Please try this:

1. Install CompizConfig
2. Using CompizConfig, disable Open GL vsync
3. Log-out, and the log-in again

It is working right now?

[Zed (darkbroodzed)]

Already downloaded and disabled. I'm try that before post bug.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Timo Aaltonen (tjaalton)]

There is a newer set of OpenGL libs since a month ago, is the performance better now?

[Zed (darkbroodzed)]

Better, but not perfect. Alt+tab still slow and some strange graphic artifacts after >20 hours of work (looks like black lines or random disappear letters)
Sometime when after enter password loginscreen broke and looks like ... hm can't describe, mb try photo it.

[Omer Akram (om26er)]

How is the situation for you in Unity 5.8.0 in Precise? Have things gotten better?

[Zed (darkbroodzed)]

in 5.8.0 better
but i don't have much time on test cose moving on new flat.

[Zed (darkbroodzed)]

i'm here again.
if someone could tell me how test performance or collect any other useful information i'll do that

[Daniel van Vugt (vanvugt)]

Was the fix for bug 942634 in Unity 5.8 not enough to solve this?

[Zed (darkbroodzed)]

> Was the fix for bug 942634 in Unity 5.8 not enough to solve this?
Nop, seems that it's not unity problem, it's ati "old" card's drivers buggy and laggy.

[Bryce Harrington (bryce)]

This is kind of a vague bug report... without tangible measures or error messages or something, it's going to be hard to say for certain what the problem is exactly, or to know when it's fixed.

But anyway...

If it is indeed a mesa problem, well I've posted a PPA with the 8.0.3 mesa which you could test: https://launchpad.net/~bryce/+archive/mesa-803

[Daniel van Vugt (vanvugt)]

Confirmed again. Even with the latest unity in precise and the latest development code for unity 6.0, the dash takes perceptibly too long to open after the super key release.

[Lonnie Lee Best (launchpad-startport)]

Accessing the Unity menu, is such a common task, that this menu should be cached or pre-rendered, so that there is absolutely no noticeable lag after you hit your super key.

It literally takes 2 or 3 seconds for the Unity menu to appear after hitting the super key.

I remember back back when Windows didn't cache their start-menu. Every time you'd click it, it had to access the hard drive before it could display it. Later, they cached that into RAM, and it made start-menu navigation more instant.

When I'm launching an application, I hit my super key, and then I have to wait for the Unity menu to come up before I begin typing. This annoyance has finally grown to the point that I'm willing to write this bug-report.

All efforts should be made to cache/pre-render this menu, so that the displaying of it will be instantaneous upon user initiation!

I want my computer to always assume that my very next task is going to be to hit my super key and display the unity menu, and I want it to be geared toward making that happen instantly.

[Lonnie Lee Best (launchpad-startport)]

Also, in my opinion, even 1 second is way too long. 100 milliseconds, however, is acceptable. This could be accomplished with pre-rendering and RAM caching. The current performance feels swap drivey!

[Lonnie Lee Best (launchpad-startport)]

Sorry, I need to mention one other thing.

I do notice that it is faster after the first time you access it. For me the very first time (after a reboot) takes about 2 or 3 seconds. Thereafter, it takes 1 second (which to me is still too long).

I'd like to see, as part of the login process, this become pre-cached/pre-rendered, before the first time I ever go to the menu. This will have a great perceptual speed increase to everyone who uses Ubuntu. This is my number one performance enhancement request for Ubuntu, and that is why I'm emphasising it so much.

This CAN be done. Even for people who have slow hardware, if designed right, this menu can be instant.

[Daniel van Vugt (vanvugt)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 814833, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find.