[coyotos-dev] Persistent Rendering Solved (?)

[Jonathan S. Shapiro]

On Mon, 2008-08-25 at 01:51 +0100, Sam Mason wrote:
> On Sun, Aug 24, 2008 at 04:30:49PM -0400, Jonathan S. Shapiro wrote:
> > I wonder if possibly I have made some progress over the last few days.
> 
> It's starting to look good.  Inductive definitions seem to indicate that
> things are progressing well to me.  I've had a few thoughts but none of
> them change the scheme in any meaningful way.  Easy questions first!
> 
> 1. Frame Buffer Objects (FBOs) seem to be required
> 
>   I didn't realize that they're so new (only approved in 2005[1]) so can
>   they be relied upon?  I'd guess they can; Mac OS X, Windows Vista and
>   latest versions of mainstream Linux distributions rely on them.

Yes and no. In effect, what I have proposed is something like a lazy
FBO. But I think that FBO's are serving a very different design purpose.

> 2. Given the reliance on FBOs, are DFBCs really the right abstraction
> 
>   Why not just render into an FBO and let whatever window system
>   that exists blit them onto the main screen?  This seems nice from
>   performance point of view, you'd only need to maintain a FBO rather
>   than a whole screen's frame buffer.

Because most acceleration hardware today is not capable of doing this.

> 3. Is it really worth *explicitly* maintaining a copy of the FBO (or
>    even DFBC) in client memory?

Yes. Without this we do not get persistence, and we would need expose
events.

>   It seems easy to arrange for the insertion of a call to upload a
>   texture containing the currently rasterised image.  This would appear
>   to simplify things by removing the need to have any explicit cache.

This call is equivalent to an expose event. It creates a covert channel.
An important but mildly subtle aspect of the current design is that a
DFBC runs trusted code. We can therefore send expose events to it that
are not revealed to the client.

In general, the DFBC cannot easily know what render commands are
required to redraw the screen. It is a potentially infinite command
stream.

shap