Re: [Qemu-devel] GTK GUI for QEmu

[Anthony Liguori <anthony@codemonkey.ws>]

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