WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Re: [PATCH 2/2] Virtual frame buffer: user space backend

To: "Anthony Liguori" <anthony@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: [PATCH 2/2] Virtual frame buffer: user space backend
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Sun, 9 Jul 2006 01:22:57 +0100
Delivery-date: Sat, 08 Jul 2006 17:23:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcaiGoUYP0fsOv0vQh2AgI7paOVWCQAzOGMA
Thread-topic: [Xen-devel] Re: [PATCH 2/2] Virtual frame buffer: user space backend
> > Well, I don't agree ;-)  Because we want to transport 2D redraw
> > information from the frontend to the backend.
> 
> So 2D information is very useful, especially for VNC.  I think for Xen
> though, we may need to abandon the shared framebuffer completely and
> develop a lightweight framebuffer protocol.
> 
> The idea would be to push the dirty'ing analysis to the frontend and
have
> it communicate data over a higher bandwidth ring queue.  This avoids
> having to deal with synchronizing the shared framebuffer for 2d ops.
> 
> This is quite a bit different from the code today though.
> 
> What do you think about getting rid of the shared framebuffer
altogether?

The shared framebuffer approach has the advantage that its very easy to
render locally (e.g. SDL), and allows the front and backends to be quite
decoupled.

I've thought about having a generic byte stream front/backend transport
and using something very VNC-like over it, but it would make the
frontend driver rather more complex (we'd need to implement one
in-kernel, and one for X). The front end would still need to have a
private framebuffer, and the communication area between front and
backend would likely need to be fairly big to avoid overrun (which would
result in a full screen resend). 

Anyhow, I really don't think its worth getting too hung up optimizing 2D
graphics performance. We need to make sure that the VNC commands that go
on the wire have the fill/copyrect optimizations, but deriving that
information in the backend isn't too expensive (with hints from the
front end).


Ian

 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>
  • RE: [Xen-devel] Re: [PATCH 2/2] Virtual frame buffer: user space backend, Ian Pratt <=