Picasa 2.7 Linux is extremely slow on Linux Guest

[Paul Siu]

I am using Picasa 2.7 Linux on Linux Mint KDE CE 4 on a Vista Host and Mandriva 2008 host and I notice that it is extremely slow. When I run Picasa, it can take up to 5 mins to appear. CPU time is running at 60% or so while idling. It's not disk related since I turned off scanning. Clicking on the Picasa menu and it takes several seconds to load. Note that I can run Picasa 2.7 at normal speed on the Mandriva 2008 host.

Looking at the task window, I think the problem may be due to Wine's interaction with Virtualbox. I notice that wineserver process runs at 30%+ and that running winecfg takes up a lot of cpu time (it should be close to nothing after launch). For some reason, wine and virtualbox don't get along.

There is at least one post in the virtuslbox forum detailing the same problem with wine.

[Paul Siu]

Here are two threads of people encountering problems with Wine

​http://forums.virtualbox.org/viewtopic.php?t=1600&highlight=wine ​http://forums.virtualbox.org/viewtopic.php?t=1981&highlight=wine

[Paul Siu]

I noticed the following bug report may be related to this:

​http://www.virtualbox.org/ticket/1759

[Paul Siu]

Vbox.Log

[Paul Siu]

I have uploaded the vbox.log relating to the issue.

[Sander van Leeuwen]

Just to clear up any confusion: you're running Picasa (which uses Wine) inside a Linux guest, correct?

[Paul Siu]

Yes, I am running Picasa 2.7 Linux, which comes with its own installation of wine 0.9.20 as a Linux guest. It rans fine under the Linux Host.

[Paul Siu]

I have ran more tests.

1. When I run winecfg, it initially causes a huge load on the cpu, but eventually drops back down.
2. I ran wine winemine and it works fine.

I am now thinking that Picasa's problem is unrelated to wine.

[juser]

I'm running mandriva 2006.0 guest inside a mandriva 2008.1 host using virtualbox 1.6.4 3308. Wanted to run kylix 3.0, wine version should be at least 6 years old (before 2002) but I encountered the same kind of behaviour as described above. Startup takes forever and using gui elements like menus and buttons is dog slow :(

[juser]

Same result with Virtualbox 2.0.2_36488. I also tried for fun (and because the wine version matches more closely the target system in terms of threading e.g.) an ancient mandriva (9.1, kernel 2.4.21)... but no luck with wine either. In fact, it felt even slower. Looks like the wineserver performs a huge amount of expensive system calls (maybe threading related?).

[Jason]

I am using software from "LearnKey" via Wine 1.1.14. This runs at native speed when installed onto an Ubuntu host, but inside an Ubuntu guest it is much, much slower.

My Ubuntu host was 8.10 running on an old Dell with 4 gb of RAM.

My Windows host is a Dual Core with 4gb of RAM, running VirtualBox 2.10 and the guest is Ubuntu 8.10 with 768mb of RAM assigned.

[Jaime Rave]

Still the same problem, using Wine 1.1.34 and Ubuntu 9.10. Virtual Box 3.1.0

[Nikolay Igotti]

Do you see slowness in both hardware accelerated and raw mode (i.e. VT-x/AMD-V on or off), or only in one of them?

[Jaime Rave]

My hardware doesn't support VT-x/AMD-V. So that option is off.

[Lubos]

I've got the same problem. Whiel googling this issue I came right to this bug report. Certainly it is a VirtualBox bug because vmware does not do this. Please, let us know how is the progress or if there is some workaround. As I'm developer and testing lot of things in wine under VBox and this is very annoying and time-consuming. Thanks for your support

[rainer]

Same problem here. I run V3.2.0 on Windows XP.

Using wine under sidux (debian sid) is extremely slow, basically unusable. Can't use it therefore.

Is any developer of VirtualBox reading this? The bug is open since 2008! I now it sounds silly to use wine under Linux under Windows-VirtualBox but believe me the Linux guest together with wine sometimes is the best possible solution. (onlinetvrecorder: decoding and cutting HQ files with Windows VirtualDub under Linux). Thanks if anybody helps ...

[Frank Mehnert]

Yes, the development team is reading this. You might have noted that there are more than 2400 more bugs open and no, the ticket priority isn't automatically raised the longer the ticket is open. Sorry.