GTK GUI for QEmu

[Anthony Liguori]

Howdy,

I started working last week on a GTK GUI for QEmu. I've made enough
progress that I wanted to share the results with everyone and collect
feedback--especially any feedback regarding what should be added/changed
for inclusion in Fabrice's tree.

Here's a rough overview of the features:

o XShmImage based display widget--initial performance tests indicate it
has identical overhead to the SDL GUI.
o GUI-based pause/save/restore/eject
o Screenshot (supporting all formats of GdkPixbuf--png, jpg, bmp, etc.)
o Video Capture (based on ffmpeg--currently uses mpeg1)
o Fullscreen mode with autohiding toolbar (thanks to
libview--http://view.sf.net)
o Software scaling (so there's no black bars in full screen mode like
with SDL)
o XEmbed support (a pygtk based POC tabbed GUI is available at
http://qemu.codemonkey.ws/qemu-tabbed.py)

You can grab a tarball at:

http://qemu.codemonkey.ws/tarballs/qemu-gtk-20051109.tar.gz

Or you can clone my hg tree with:

hg clone http://qemu.codemonkey.ws/hg/gtk

A couple screenshots are available at:

http://qemu.codemonkey.ws/screenshots/

Any feedback is greatly appreciated. A bunch of stuff is not there yet
(there's barely any accelerator support so you can't get to the monitor
yet) and I haven't tested on non true color X servers so your results
may vary.

Regards,

Anthony Liguori

[Oliver Gerlich]

Post by Anthony Liguori
Howdy,
I started working last week on a GTK GUI for QEmu. I've made enough
progress that I wanted to share the results with everyone and collect
feedback--especially any feedback regarding what should be added/changed
for inclusion in Fabrice's tree.
o XShmImage based display widget--initial performance tests indicate it
has identical overhead to the SDL GUI.
o GUI-based pause/save/restore/eject
o Screenshot (supporting all formats of GdkPixbuf--png, jpg, bmp, etc.)
o Video Capture (based on ffmpeg--currently uses mpeg1)
o Fullscreen mode with autohiding toolbar (thanks to
libview--http://view.sf.net)
o Software scaling (so there's no black bars in full screen mode like
with SDL)
o XEmbed support (a pygtk based POC tabbed GUI is available at
http://qemu.codemonkey.ws/qemu-tabbed.py)
http://qemu.codemonkey.ws/tarballs/qemu-gtk-20051109.tar.gz
hg clone http://qemu.codemonkey.ws/hg/gtk
http://qemu.codemonkey.ws/screenshots/
Any feedback is greatly appreciated. A bunch of stuff is not there yet
(there's barely any accelerator support so you can't get to the monitor
yet) and I haven't tested on non true color X servers so your results
may vary.
Regards,
Anthony Liguori
_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Hi,

just a short feedback on your qemu gui:

- -looks nice so far :)
- -does it require a new(er) GTK? I only have 2.6.10 installed here, maybe
that's why it doesn't find "GTK_STOCK_LEAVE_FULLSCREEN"
- -make install misses "camera.png"
- -the toolbar functions are useful (would be bad if they wouldn't ;)
- -the toolbar hiding in fullscreen mode is really cool
- -the software scaler is maybe a good idea, but for fullscreen mode, I'd
better like to have screen resolution switched to qemu guest resolution
(as it is with normal qemu now)
- -sometimes the mouse can't be moved beyond some point on the guest
screen... But I don't know when that happens and cannot really reproduce it
- -"mouse button up" events seem to be delayed somewhat: when clicking on
an icon on the desktop of a Windows guest and releasing the mouse
button, then dragging the mouse will drag the icon a bit
- -the windows key doesn't seem to work

Apart from these (minor) glitches I quite liked the GUI. Btw. for the
fullscreen mode you might want to have a look at the thread about Jim's
GTK GUI - these issues have already been talked about there.

Oliver

[Jim C. Brown]

Post by Oliver Gerlich
- -the software scaler is maybe a good idea, but for fullscreen mode, I'd
better like to have screen resolution switched to qemu guest resolution
(as it is with normal qemu now)

The problem is that is really hard to do. Especially in a cross platform
manner.

I couldn't figure out how to scale it for full screen, but that was my original
plan. Another benefit of scaling is that you can resize the window without harm:
if the text is too small to read then just make the window bigger.

Post by Oliver Gerlich
- -sometimes the mouse can't be moved beyond some point on the guest
screen... But I don't know when that happens and cannot really reproduce it

I think I know what you're talking about. I had this problem with my gtk code
as well. This is because the host and guest pointers are not 'sync'ed, so when
the host mouse hits the edge of the screen, the guest pointer also halts (even
if it's not at the edge). GTK provides no way to fix this - basically you need
to test when the pointer is at the edge and warp it to the opposite side. But
this requires platform specific code (however I did write up the X and Windows
versions).

The cause of the problem becomes quite obvious if you don't make the host
pointer invisible when you grab the mouse.

[Oliver Gerlich]

Post by Jim C. Brown

Post by Oliver Gerlich
- -the software scaler is maybe a good idea, but for fullscreen mode, I'd
better like to have screen resolution switched to qemu guest resolution
(as it is with normal qemu now)

The problem is that is really hard to do. Especially in a cross platform
manner.
I couldn't figure out how to scale it for full screen, but that was my original
if the text is too small to read then just make the window bigger.

Post by Oliver Gerlich
- -sometimes the mouse can't be moved beyond some point on the guest
screen... But I don't know when that happens and cannot really reproduce it

I think I know what you're talking about. I had this problem with my gtk code
as well. This is because the host and guest pointers are not 'sync'ed, so when
the host mouse hits the edge of the screen, the guest pointer also halts (even
if it's not at the edge). GTK provides no way to fix this - basically you need
to test when the pointer is at the edge and warp it to the opposite side. But
this requires platform specific code (however I did write up the X and Windows
versions).
The cause of the problem becomes quite obvious if you don't make the host
pointer invisible when you grab the mouse.

Wouldn't these two things be solved by using SDL inside the GTK window?
In current qemu, there are neither fullscreen nor mouse moving problems.

Fabrice mentioned some time ago that SDL isn't the best choice on
Windows because of keyboard issues... Is that still the case?

Oliver

PS: Arrg... no need to wonder why the mail doesn't appear on the list -
I replied to Jim only. Here it is again.

[Anthony Liguori]

Post by Oliver Gerlich
Wouldn't these two things be solved by using SDL inside the GTK window?
In current qemu, there are neither fullscreen nor mouse moving problems.

Depending on the X server settings, certain modes aren't available in
SDL. In particular, on the default X install in Ubuntu on my system,
there is not a mode to handle the standard console mode in Linux which
means you get a centered console with large bars on the edges. It's
very ugly.

The mouse problem occurs less frequently in SDL because of the fact that
you're always at native resolution (so the mouse moves around the screen
almost as quickly as it normally would. It's definitely reproducible.
If you disable the mouse hiding in SDL mode, and you move the mouse
slowly from one edge to another, you'll hit the box.

Post by Oliver Gerlich
Fabrice mentioned some time ago that SDL isn't the best choice on
Windows because of keyboard issues... Is that still the case?

Probably. I was hoping to punt on the issue of Win32 and instead rely
on a native Win32 GUI. I'm not sure GTK on Win32 is going to be that
great from a performance perspective.

FWIW, I'm going to benchmark the my latest optimizations for fullscreen
mode and post the results later today. If scaling can be done with
little performance impact, I think it's clearly the right thing to do.

Regards,

Anthony Liguori

Post by Oliver Gerlich
Oliver
PS: Arrg... no need to wonder why the mail doesn't appear on the list
- I replied to Jim only. Here it is again.
_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Oliver Gerlich]

Post by Anthony Liguori

Post by Oliver Gerlich
Wouldn't these two things be solved by using SDL inside the GTK window?
In current qemu, there are neither fullscreen nor mouse moving problems.

Depending on the X server settings, certain modes aren't available in
SDL. In particular, on the default X install in Ubuntu on my system,
there is not a mode to handle the standard console mode in Linux which
means you get a centered console with large bars on the edges. It's
very ugly.
The mouse problem occurs less frequently in SDL because of the fact that
you're always at native resolution (so the mouse moves around the screen
almost as quickly as it normally would. It's definitely reproducible.
If you disable the mouse hiding in SDL mode, and you move the mouse
slowly from one edge to another, you'll hit the box.

Post by Oliver Gerlich
Fabrice mentioned some time ago that SDL isn't the best choice on
Windows because of keyboard issues... Is that still the case?

Probably. I was hoping to punt on the issue of Win32 and instead rely
on a native Win32 GUI. I'm not sure GTK on Win32 is going to be that
great from a performance perspective.
FWIW, I'm going to benchmark the my latest optimizations for fullscreen
mode and post the results later today. If scaling can be done with
little performance impact, I think it's clearly the right thing to do.
Regards,
Anthony Liguori

Post by Oliver Gerlich
Oliver
PS: Arrg... no need to wonder why the mail doesn't appear on the list
- I replied to Jim only. Here it is again.
_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel

_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel

I agree that a software scaling mode is useful, for the reasons you
stated. But nonetheless I think a resolution-switching fullscreen mode
is useful as well :) eg. because software scaling doesn't look as nice
as native resolution (at least on CRTs, it's unnecessaryly pixelated or
blurred). And if we would have a completely different GUI implementation
for Windows anyway, the GTK GUI could indeed use direct X11 calls (or
the like) to switch resolutions.

So, I pledge to include both methods (software scaling and switch to
native resolution) in the GUI and decide which mode to use based on user
preference or some clever algorithm :D

Regards,
Oliver

[Jim C. Brown]

Post by Anthony Liguori

Post by Oliver Gerlich
Fabrice mentioned some time ago that SDL isn't the best choice on
Windows because of keyboard issues... Is that still the case?

Probably. I was hoping to punt on the issue of Win32 and instead rely
on a native Win32 GUI. I'm not sure GTK on Win32 is going to be that
great from a performance perspective.

I haven't tried to benchmark that case. The bigger issue with GTK on W32 was
the need for a 3rd party library (too large, too hard to install, etc etc).

I wouldn't rely on the hope of a native W32 gui showing up anytime soon though.
Yours is the third attempt to bring a native GTK gui to qemu - AFAIK we have
yet to see the first attempt for a W32 gui.

By taking advantage of GTK's portability, we can get a consistent GUI across
both platforms, and have the developers (the majority of whom are on Unix)
work on code which benefits the users (many of whom use W32).

Fabrice also wants a native W32 gui, and that is not really a bad idea. But
since GTK code is so easy to use on both W32 and on Unix/X, I think that any
GTK gui for qemu should support both until the native version arrives.

Post by Anthony Liguori
FWIW, I'm going to benchmark the my latest optimizations for fullscreen
mode and post the results later today. If scaling can be done with
little performance impact, I think it's clearly the right thing to do.

I don't necessarily see a problem with adding support for changing the X server
resolution. However, it is probably harder to do right - it is really difficult
to center the viewport on just the window you want and nothing else. I can't
really think of any advantages in making the host handle this.

[Anthony Liguori]

Post by Jim C. Brown

Post by Anthony Liguori
Probably. I was hoping to punt on the issue of Win32 and instead rely
on a native Win32 GUI. I'm not sure GTK on Win32 is going to be that
great from a performance perspective.

I haven't tried to benchmark that case. The bigger issue with GTK on W32 was
the need for a 3rd party library (too large, too hard to install, etc etc).

There's a significant performance difference between using XShmImage's
and client-side images. Obviously, XShmImage's are only available on
X11. There are better ways to do it on Windows.

Post by Jim C. Brown
I wouldn't rely on the hope of a native W32 gui showing up anytime soon though.
Yours is the third attempt to bring a native GTK gui to qemu - AFAIK we have
yet to see the first attempt for a W32 gui.

I have no problem writing a Win32 GUI if it's needed to get a good GTK
GUI. This is the primary reason I didn't attempt to handle VM creation
in the GUI. Better to start at something simple and improve incrementally.

Post by Jim C. Brown

Post by Anthony Liguori
FWIW, I'm going to benchmark the my latest optimizations for fullscreen
mode and post the results later today. If scaling can be done with
little performance impact, I think it's clearly the right thing to do.

I don't necessarily see a problem with adding support for changing the X server
resolution. However, it is probably harder to do right - it is really difficult
to center the viewport on just the window you want and nothing else. I can't
really think of any advantages in making the host handle this.

Well, I remembered why I didn't like this earlier. If you change the
resolution, the autohiding toolbar is going to appear much larger than
it should. This is going to be an accessibility nightmare.

On a CPU-bound workload, using a very microbenchmark, the overhead of
the current scaling is about 10%. That's actually better than I
expected. I'm confident it could be brought down to about 5%. Again,
this is for a CPU bound workload. If you're using kqemu and you're not
at 100% CPU utilization you wouldn't notice the difference.

Regards,

Anthony Liguori

[Jim C. Brown]

Post by Anthony Liguori

Post by Jim C. Brown
I don't necessarily see a problem with adding support for changing the X server
resolution. However, it is probably harder to do right - it is really difficult
to center the viewport on just the window you want and nothing else. I can't
really think of any advantages in making the host handle this.

Well, I remembered why I didn't like this earlier. If you change the
resolution, the autohiding toolbar is going to appear much larger than
it should. This is going to be an accessibility nightmare.

That is a good point. Ultimately, you'd need to use scaling anyways to fix that.
So then changing host resolutions gives no benefits at extra overhead.

I think this issue has been settled.

Post by Anthony Liguori
On a CPU-bound workload, using a very microbenchmark, the overhead of
the current scaling is about 10%. That's actually better than I
expected. I'm confident it could be brought down to about 5%. Again,
this is for a CPU bound workload. If you're using kqemu and you're not
at 100% CPU utilization you wouldn't notice the difference.

Actually, one probably won't even notice the 10% utilization. Performance isn't
the biggest issue here. If one really cared about qemu's cpu usage, then ideally
that person should start qemu without a GUI anyways.

Post by Anthony Liguori
There's a significant performance difference between using XShmImage's
and client-side images. Obviously, XShmImage's are only available on
X11. There are better ways to do it on Windows.
I have no problem writing a Win32 GUI if it's needed to get a good GTK
GUI. This is the primary reason I didn't attempt to handle VM creation
in the GUI. Better to start at something simple and improve incrementally.

You mean writing W32 code for the GTK gui? You'll have to, if you want the
GTK gui to work on all platforms. If you don't, then you don't have to touch
W32 programming at all, and you can still get a perfectly good GUI for .. erm ..
Linux.

But aren't the users who'd benefit the most from the GUI using Windows hosts?

If it was a lot of work to get GTK to work with Windows, then it would probably
be wasted effort. Lots of work into something that will eventually be chucked out.

But since it isn't a lot of work, I don't see the problem. I had a harder time
because I wasn't familiar with W32 programming, but the changes I had to make
to get it to work were small. So with a little extra work, you can get two
identical user interfaces on two very different OSes. Sounds like a good tradeoff
to me.

The reason I bring this up is because, unless the designer of the W32 and the GTK
gui are the same person, the two guis will probably look the very different. The
real issue is to get a consistent interface on all platforms.

Now, if you mean you'll work on a pure W32 gui once you've fleshed out and
battle-tested the GTK gui's design, I'll be quiet and let you get back to work. ;)

Post by Anthony Liguori
Regards,
Anthony Liguori

[Anthony Liguori]

Post by Jim C. Brown
You mean writing W32 code for the GTK gui?

Nopes :-)

Post by Jim C. Brown
Now, if you mean you'll work on a pure W32 gui once you've fleshed out and
battle-tested the GTK gui's design, I'll be quiet and let you get back to work. ;)

Yup, that's what I mean. I've done a fair bit of Win32 programming.
Since the GTK version only took a few days to do, a Win32 version
shouldn't take much more. Installing mingw32 as we speaking...

Regards,

Anthony Liguori

Post by Jim C. Brown

Post by Anthony Liguori
Regards,
Anthony Liguori

[Jernej Simonèiè]

Post by Anthony Liguori
Yup, that's what I mean. I've done a fair bit of Win32 programming.
Since the GTK version only took a few days to do, a Win32 version
shouldn't take much more. Installing mingw32 as we speaking...

Since compiling GTK+ on Windows is a nightmare, you should use the
precompiled libraries provided by Tor Lillqvist. 2.6 is available at his
page <http://www.gimp.org/~tml/gimp/win32/downloads.html>, while 2.8 (which
doesn't work on 98/ME anymore) is here: <ftp://ftp.gtk.org/pub/gtk/v2.8/win32/>

If you're having trouble setting up the build environment, check out this Gimp
wiki page: <http://wiki.gimp.org/gimp/HowToCompileGimpMicrosoftWindowsOld>

[Anthony Liguori]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,

Hi Oliver,
Appreciated :-)

- -looks nice so far :)
- -does it require a new(er) GTK? I only have 2.6.10 installed here, maybe
that's why it doesn't find "GTK_STOCK_LEAVE_FULLSCREEN"

I'm using 2.8.6. I didn't realize that stock item was missing, I'll
include it in the next tarball for older versions of gtk.

- -make install misses "camera.png"

Oops, sorry, I'll fix that too.

- -the software scaler is maybe a good idea, but for fullscreen mode, I'd
better like to have screen resolution switched to qemu guest resolution
(as it is with normal qemu now)

I think a comprise may be the best solution. Perhaps switch to the
closest X resolution available and use software scaling to get you the
rest of the way there.

On at least one of my systems, I only have X set to use a single
resolution. I think that's common enough that it should be handled.

- -sometimes the mouse can't be moved beyond some point on the guest
screen... But I don't know when that happens and cannot really reproduce it

As Jim mentioned, this is a difficult thing to get right and I don't
currently try to work around it at all. The problem occurs when the
mouse hits the edge of the physical screen. The solution is most
certainly to warp the mouse back to the center of the screen when it
hits an edge.

FWIW, it's possible to reproduce this bug in the SDL version too.

- -"mouse button up" events seem to be delayed somewhat: when clicking on
an icon on the desktop of a Windows guest and releasing the mouse
button, then dragging the mouse will drag the icon a bit

Interesting, I'll have to look into this.

- -the windows key doesn't seem to work

I'll find a keyboard with a windows key and figure out the proper scancode.

Apart from these (minor) glitches I quite liked the GUI. Btw. for the
fullscreen mode you might want to have a look at the thread about Jim's
GTK GUI - these issues have already been talked about there.

Thanks for the feedback!

Regards,

Anthony Liguori

Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDc9ifTFOM6DcNJ6cRAv+GAKCO2H5ygQZ/EaqONKEJlfcgeBUhYwCfSs3N
1W4s9lCI2EijvwnptDQrkMM=
=zEgy
-----END PGP SIGNATURE-----
_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel