[Qemu-devel] GTK GUI for QEmu

[Qemu-devel] 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

Re: [Qemu-devel] GTK GUI for QEmu

[Oliver Gerlich]

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

Anthony Liguori schrieb:
> 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
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDc9ifTFOM6DcNJ6cRAv+GAKCO2H5ygQZ/EaqONKEJlfcgeBUhYwCfSs3N
1W4s9lCI2EijvwnptDQrkMM=
=zEgy
-----END PGP SIGNATURE-----

Re: [Qemu-devel] GTK GUI for QEmu

[Jim C. Brown]

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

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

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] GTK GUI for QEmu

[Oliver Gerlich]

Jim C. Brown wrote:
>>- -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.
> 
> 
>>- -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.

Re: [Qemu-devel] GTK GUI for QEmu

[Anthony Liguori]

Oliver Gerlich wrote:

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

> 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

> 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
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] GTK GUI for QEmu

[Oliver Gerlich]

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

Anthony Liguori schrieb:
> Oliver Gerlich wrote:
> 
>> 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.
> 
>> 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
> 
>> 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
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDdPE+TFOM6DcNJ6cRAjphAJ9guWOfpEIrIN59aoScIYLnpzroGQCffA0y
fyB18E5nduwOHrD9ByeOaPI=
=8kkl
-----END PGP SIGNATURE-----

Re: [Qemu-devel] GTK GUI for QEmu

[Jim C. Brown]

On Fri, Nov 11, 2005 at 12:55:12PM -0600, Anthony Liguori wrote:
> >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.

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

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] GTK GUI for QEmu

[Anthony Liguori]

Jim C. Brown wrote:

>On Fri, Nov 11, 2005 at 12:55:12PM -0600, Anthony Liguori wrote:
>  
>
>>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. 

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

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

Re: [Qemu-devel] GTK GUI for QEmu

[Jim C. Brown]

On Fri, Nov 11, 2005 at 02:39:01PM -0600, Anthony Liguori wrote:
> Jim C. Brown wrote:
> 
> >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.

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

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

> Regards,
> 
> Anthony Liguori
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] GTK GUI for QEmu

[Anthony Liguori]

Jim C. Brown wrote:

>
>You mean writing W32 code for the GTK gui?
>
Nopes :-)

>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

>>Regards,
>>
>>Anthony Liguori
>>
>>    
>>
>
>  
>

Re: [Qemu-devel] GTK GUI for QEmu

[Jernej Simonèiè]

On Friday, November 11, 2005, 23:06:57, Anthony Liguori wrote:

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

-- 
< Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >

If you're feeling good, don't worry. You'll get over it.
       -- Boling's Postulate

Re: [Qemu-devel] GTK GUI for QEmu

[Anthony Liguori]

Oliver Gerlich wrote:

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

>just a short feedback on your qemu gui:
>  
>
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
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>  
>