Poor video playback performance with radeon driver and compositing

Hi TJ, and thanks for reporting this bug!
Could you please try to play a video in a different session than Unity2D (such as Unity 3D, Ubuntu classic or GNOME -- whatever works :-) )?

Then, if you open the gconf-editor and navigate to apps/metacity/general/, what value has the compositing_manager key? You could also try to toggle it, restart the session, and see if the situation improves (remember then to bring it back to its original value).

This should help us debug the issue.

No problem with the bug reporting; glad I can help in some small way.
As far as logging into 3D, that's a no go. On this machine, Ubuntu defaults to 2D period (on 11.04 I had the "classic" interface — a classic interface that let me play videos, I may add ;) ). Anyway, joking aside, GNOME 3 also won't work/won't install.
So what I've done on top of this set up is:

sudo apt-get install lubuntu-desktop

And wouldn’t you know it, watching videos in Lubuntu just works, all video formats, all players.
So then I logged back into Unity 2D. As far as the compositing_manager key, first I had to install gconf-editor from the repos. Then, in Unity 2D, compositing_manager key was set to “False.” I switched it to “true,” logged out, and logged back in again. Watching a video in VLC doesn’t go into “slow-motion” mode, but it drops frames like mad and the video is pretty much unwatchable. Banshee and Gnome Mplayer, however, are still in slow-motion — clear, no frames dropped, but playing at a fraction of the speed it should.
So then I went and toggled the manager back to “false” and now the videos now play glitch free and without a problem in Unity 2D — in all the media players. I should also add that I didn’t log out and back in after toggling back to “false”; it was more of a what-the-heck try it and see moment.

So what I'm doing right now is waiting for the updates to finish installing on a second test machine (same laptop, but with 512 megs of ram instead of a gig) and I will toggle compositing_manager key without installing another UI (Lubuntu) to see what happens. I will post the results when this is done.

On the second test machine, compositing_manager was set to "true" by default (I guess installing Lubuntu on the other machine may have set it to "false" before I had a chance to check).
I set compositing_manager to "false" on this second machine, and now it plays videos fine across the board on all media players -- even with its measly 512 megs of ram.

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

Thanks TJ for the infos.
I'm asking you some more, as I don't seem to be able to reproduce the issue here.

- If you turn the compositing_manager to true again, do the problem reappear?

- You mentioned in the first post that you had Intel graphics; but the bug report tool claims you have an ATI radeon mobility. Can you please clarify? Also, are you using any of the closed source drivers (e.g., fglrx)?

- Is your laptop connected to the A/C power? I wonder if it's sluggish because of some power saving mode.

- If you run "top" while watching a video, do you see other processes eating a good part of CPU power, besides the player? And how much CPU power is taken by the player itself?

- If you run the player as fullscreen (from the very beginning), does the situation improve?

- If you turn the compositing_manager to true again, do the problem reappear?

Yes, after turning on the compositing_manager back on, the problem reappears

- You mentioned in the first post that you had Intel graphics; but the bug report tool claims you have an ATI radeon mobility. Can you please clarify? Also, are you using any of the closed source drivers (e.g., fglrx)?

That was my mistake. I’ve never had problems with video/graphics on this machine, so I always assumed it was an Intel chipset. However, after digging deeper, these test machines do have ATI graphics. I am not using any closed graphics drivers; everything is stock.

- Is your laptop connected to the A/C power? I wonder if it's sluggish because of some power saving mode.

All laptops are connected to AC. I’ve even removed the batteries to see if that may be an issue, but it is still sluggish.

- If you run "top" while watching a video, do you see other processes eating a good part of CPU power, besides the player? And how much CPU power is taken by the player itself?
I don’t think the reading is accurate (probably because the system is freezing up), but it says VLC is using 6% CPU (although it is “sleeping”)

Here’s the rundown of the most memory-intensive while watching the video full-screen in VLC with compositing_manager on “true”:
vlc: 6% cpu, memory 32.5 mb
ubuntuone-syncdaemon 0% cpu, memory 20.2 mb
unity-2d-places 0% cpu, memory 12.8 mb
metacity 0% cpu, memory 7.7 mb
unity panel service 0% cpu, memory 7.6 mb
applet.py 0% cpu, memory 7.5 mb
zeitgeist-daemon 0% cpu, memory 7.4 mb

Interestingly, all these are listed as “sleeping”

- If you run the player as fullscreen (from the very beginning), does the situation improve?

Fullscreen from the very beginning is even worse than attempting in “small screen”; it almost freezes up the computer completely, and when I press escape or try to close the video, it takes at least a minute to respond.

@TJ I'd try with fglrx, that will probably help. The radeon drivers probable aren't performant enough to play videos in a composited env.

I tried the fglrx driver and it works. I can play videos now in full-screen, which is good.
I guess I will have to get used to installing this driver, instead of running "stock."
So is this issue still considered a bug? It is a result of Unity 2d now being default, as I never had this video trouble in classic Gnome; right out of the box, Unity doesn't work for everything.
I'm interested in seeing what you all think.
Cheers!

It looks like Michal was correct in comment #7. One thing that might improve the performance of the open-source radeon drivers slightly in the latest upstream 3.0.18 kernel is this patch:

commit a674b8b3e345496a96aec389446650455b2fdfa1
Author: Alex Deucher
Date: Tue Jan 3 09:48:38 2012 -0500

    drm/radeon/kms: disable writeback on pre-R300 asics

    commit 28eebb703e28bc455ba704adb1026f76649b768c upstream.

    We often end up missing fences on older asics with
    writeback enabled which leads to delays in the userspace
    accel code, so just disable it by default on those asics.

    Reported-by: Helge Deller
    Reported-by: Dave Airlie
    Signed-off-by: Alex Deucher
    Signed-off-by: Dave Airlie
    Signed-off-by: Greg Kroah-Hartman

A PPA of kernel 3.0.18 is available at http://kernel.ubuntu.com/~kernel-ppa/mainline/

If the upcoming Ubuntu 12.10 "Quantal Quetzal" pulls in version 6.14.4 of the open-source radeon driver, released on 28 March 2012 (or the just-released 6.14.5 version), you might get a small performance improvement on your old Radeon Mobility 7500 due to the implementation of KMS tiling. KMS tiling was already supported on newer Radeon hardware.

You can monitor the driver git snapshot dates at https://launchpad.net/ubuntu/+source/xserver-xorg-video-ati