qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Jim C. Brown" <jma5@umd.edu>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] GTK GUI for QEmu
Date: Fri, 11 Nov 2005 17:03:04 -0500	[thread overview]
Message-ID: <20051111220304.GA24808@jbrown.mylinuxbox.org> (raw)
In-Reply-To: <43750165.4060906@codemonkey.ws>

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	other threads:[~2005-11-11 22:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-09 22:07 [Qemu-devel] GTK GUI for QEmu Anthony Liguori
2005-11-10 23:32 ` Oliver Gerlich
2005-11-11  3:45   ` Jim C. Brown
2005-11-11 16:13     ` Oliver Gerlich
2005-11-11 18:55       ` Anthony Liguori
2005-11-11 19:30         ` Oliver Gerlich
2005-11-11 20:11         ` Jim C. Brown
2005-11-11 20:39           ` Anthony Liguori
2005-11-11 22:03             ` Jim C. Brown [this message]
2005-11-11 22:06               ` Anthony Liguori
2005-11-11 22:46                 ` Jernej Simonèiè
2005-11-11 15:35   ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051111220304.GA24808@jbrown.mylinuxbox.org \
    --to=jma5@umd.edu \
    --cc=anthony@codemonkey.ws \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).