Xen devel - Jul 2006 - RE: 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@lists.xensource.com
http://lists.xensource.com/xen-devel