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