qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Ongoing changes to the displaying code
Date: Sat, 10 Jan 2009 00:01:02 +0000	[thread overview]
Message-ID: <20090110000101.GB1972@shareable.org> (raw)
In-Reply-To: <49679E7F.6050504@codemonkey.ws>

Anthony Liguori wrote:
> >>Of course, with the right VNC extension to support a shared memory 
> >>transport, I still contend VNC can be just as efficient as SDL.
> >>    
> >
> >It still puts a big speed and flexibility limit IMHO.
> 
> Why?  There's no additional memory copying.  There's a very small update 
> latency addition.

Fwiw, I agree with Anthony.

If VNC performance is a concern (it probably should be when you want
to do to video, or 1:1 full-screen, or 3d, or vsync-locked display),
extending localhost VNC to be as good as any "native" display method
can be would be the best way forward.

Obviously this would involve (at least) shared memory with both the X
server and QEMU, to remove all image copying and conversion when possible.
Similar mechanisms can be found on Windows and MacOS X.

SDL is good at some things but it's not perfect itself.  It may even
be better to remove SDL from QEMU proper, and provide a separate
localhost-VNC-to-SDL client.  (Same for the other frontends?)
Localhost-VNC does not need to support the whole VNC protocol, only
that used in localhost-VNC mode.

The other concern with VNC might be its complexity means you really
always want to use the existing VNC client library, which may not be a
desirable dependency for some applications.  For this, localhost-VNC
being both an extension to VNC and a subset of it would be helpful, as
you wouldn't have to use a full-fledged VNC client library for local
GUI apps if that isn't wanted.

-- Jamie

  reply	other threads:[~2009-01-10  0:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-09  1:52 [Qemu-devel] Ongoing changes to the displaying code Daniel Gutson
2009-01-09  2:50 ` Anthony Liguori
2009-01-09  3:04   ` Anthony Liguori
2009-01-09  9:28     ` David Turner
2009-01-09 15:20       ` Anthony Liguori
2009-01-09 16:53         ` David Turner
2009-01-09 17:16         ` Ian Jackson
2009-01-09 17:24           ` Anthony Liguori
2009-01-09 17:42             ` Riku Voipio
2009-01-09 18:59               ` Anthony Liguori
2009-01-10  0:01                 ` Jamie Lokier [this message]
2009-01-10  1:39                   ` Anthony Liguori
2009-01-12 15:25                 ` Ian Jackson
2009-01-15  8:53                 ` Mark McLoughlin
2009-01-09 17:26           ` David Turner
2009-01-09 19:02             ` Anthony Liguori
2009-01-12 15:31             ` Ian Jackson
2009-01-11  8:22     ` Avi Kivity
2009-01-12 15:33       ` Ian Jackson
2009-01-12 15:57         ` Avi Kivity
2009-01-09 12:04 ` Stefano Stabellini

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=20090110000101.GB1972@shareable.org \
    --to=jamie@shareable.org \
    --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).