From: "Daniel P. Berrange" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window
Date: Thu, 4 Sep 2008 10:42:26 +0100 [thread overview]
Message-ID: <20080904094226.GB11424@redhat.com> (raw)
In-Reply-To: <48BF4F4F.40208@codemonkey.ws>
On Wed, Sep 03, 2008 at 10:00:31PM -0500, Anthony Liguori wrote:
> Stefano Stabellini wrote:
> >This patch comes from xen-unstable and adds opengl support for rendering
> >the guest framebuffer in the SDL window.
> >SDL is needed anyway to open the window and handle the events.
> >Opengl rendering is optional and can be turned off at both compile time
> >and run time (--disable-opengl).
> >Some of the benefits of using opengl are:
> >
> >-faster rendering, less CPU intensive, especially with good graphic
> >cards;
> >
>
> Have you measured this or is this just intuition? I've measured it with
> gtk-vnc and I did not observe any CPU usage decrease in using OpenGL for
> rendering verses an XShmImage.
>
> >-makes the window resizing possible and hardware accelerated, thus very
> >efficient and smooth;
> >
>
> This is neat, but, I'm unsure if the right way to support OpenGL is
> through SDL. For instance, there were Cocoa OpenGL patches posted a bit
> ago that would be largely similar. It may make more sense to have an
> OpenGL front-end that has conditional code for SDL/Cocoa/X/etc.
>
> Then again, I've been kicking around the idea of doing a GTK front-end.
> An obvious thing to do here would be a glext based OpenGL version (as we
> do in gtk-vnc).
Actually I'm not so sure this was a good idea in the end. I'm seriously
considering re-writing the GTK-VNC stuff to use Cairo, which in turn
can use 2-d hardware acceleration primitives - it really doesn't need
the full 3-d acceleration stack just for scaling.
> I think we need to have some discussion about what the long term
> front-end should be for QEMU. Otherwise, we're going to end up with a
> proliferation of front-ends. Personally, I'd rather move from SDL to
> GTK so that we can build a proper user interface.
As long as that's optional, because in a server deployment scenario like
oVirt I don't want to pull in the GTK stack just to run QEMU vms. We currently
have a minimal OS image target of < 64 MB in size. Adding GTK and its deps
will totally blow that limit.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
next prev parent reply other threads:[~2008-09-04 9:42 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-29 15:22 [Qemu-devel] [PATCH] opengl rendering in the sdl window Stefano Stabellini
2008-09-02 16:53 ` Ian Jackson
2008-09-04 3:00 ` Anthony Liguori
2008-09-04 7:41 ` Gerd Hoffmann
2008-09-04 9:42 ` Daniel P. Berrange [this message]
2008-09-04 10:06 ` Andreas Färber
2008-09-04 10:20 ` Daniel P. Berrange
2008-09-05 16:42 ` Andreas Färber
2008-09-07 7:51 ` Avi Kivity
2008-09-07 3:07 ` Anthony Liguori
2008-09-07 16:31 ` Daniel P. Berrange
2008-09-08 0:12 ` Anthony Liguori
2008-09-04 10:06 ` Stefano Stabellini
2008-09-05 12:02 ` Jamie Lokier
2008-09-05 12:11 ` Samuel Thibault
2008-09-06 23:27 ` Jamie Lokier
2008-09-07 14:22 ` Samuel Thibault
2008-09-07 14:36 ` Paul Brook
2008-09-07 14:42 ` Samuel Thibault
2008-09-07 15:03 ` Paul Brook
2008-09-07 15:12 ` Samuel Thibault
2008-09-07 15:35 ` Paul Brook
2008-09-07 15:41 ` Samuel Thibault
2008-09-07 15:57 ` Paul Brook
2008-09-08 0:08 ` Anthony Liguori
2008-09-08 0:21 ` Samuel Thibault
2008-09-08 1:18 ` Jamie Lokier
2008-09-08 10:38 ` Stefano Stabellini
2008-09-08 13:21 ` Jamie Lokier
2008-09-05 16:44 ` Stefano Stabellini
2008-09-05 16:55 ` Daniel P. Berrange
2008-09-05 17:13 ` Stefano Stabellini
2008-09-07 3:21 ` Anthony Liguori
2008-09-08 10:48 ` Stefano Stabellini
2008-09-08 13:16 ` Jamie Lokier
2008-09-08 13:51 ` Stefano Stabellini
2008-09-08 13:41 ` Jamie Lokier
2008-09-08 13:48 ` Daniel P. Berrange
2008-09-08 14:56 ` Gerd Hoffmann
2008-09-08 15:08 ` Jamie Lokier
2008-09-08 15:35 ` Gerd Hoffmann
2008-09-08 15:39 ` Jamie Lokier
2008-09-08 16:23 ` Gerd Hoffmann
2008-09-08 16:47 ` Anthony Liguori
2008-09-08 19:15 ` Gerd Hoffmann
2008-09-08 19:43 ` Jamie Lokier
2008-09-08 15:47 ` Daniel P. Berrange
2008-09-08 16:05 ` Anthony Liguori
2008-09-08 17:08 ` Mike Kronenberg
2008-09-08 19:21 ` Gerd Hoffmann
2008-09-08 21:06 ` Mike Kronenberg
2008-09-08 19:32 ` Jamie Lokier
2008-09-08 19:48 ` Jamie Lokier
2008-09-08 19:57 ` Anthony Liguori
2008-09-08 20:11 ` Jamie Lokier
2008-09-08 23:18 ` Daniel P. Berrange
2008-09-09 0:10 ` Jamie Lokier
2008-09-09 2:45 ` Anthony Liguori
2008-09-09 4:17 ` Jamie Lokier
2008-09-08 14:22 ` Anthony Liguori
2008-09-07 7:48 ` Avi Kivity
2008-09-07 11:57 ` Daniel P. Berrange
2008-09-07 13:12 ` Avi Kivity
2008-09-08 10:30 ` Stefano Stabellini
2008-09-08 10:35 ` Daniel P. Berrange
2008-09-08 10:53 ` Stefano Stabellini
2008-09-08 11:00 ` Daniel P. Berrange
2008-09-08 12:38 ` François Revol
2008-09-08 13:05 ` Jamie Lokier
2008-09-08 13:08 ` Anthony Liguori
2008-09-08 13:44 ` François Revol
2008-09-05 18:11 ` malc
2008-09-04 10:14 ` Stefano Stabellini
2008-09-07 3:09 ` Anthony Liguori
2008-09-04 10:21 ` Andreas Färber
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=20080904094226.GB11424@redhat.com \
--to=berrange@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.