Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Daniel P. Berrange]

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 :|