qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] GTK GUI for QEmu


From: Jim C. Brown
Subject: Re: [Qemu-devel] GTK GUI for QEmu
Date: Fri, 11 Nov 2005 17:03:04 -0500
User-agent: Mutt/1.4.2.1i

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]