Comment 6 for bug 852554

- 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.