Can someone explain to me why persisting the framebuffer is needed at all?
Whatever GUI EROS ends up having, it will be aware of all the programs currently displaying something. On restart after a "crash" is it really so difficult for the GUI to iterate its list of programs and signal them to redraw/invalidate? The programs will have no problem redrawing exactly what the user saw before the crash because all their internal state is also persisted. This is all hopefully at a layer or three above the framebuffer.
Things writing directly to the framebuffer (such as polygon-pushing games) should have to worry about reconstructing framebuffer state themselves. With some sort of "just-crashed" signal being sent to them on restart, this shouldn't be so difficult. This same signal would be sent to the GUI to tell it to invalidate all its clients' displays.
I am not a graphics programmer in any respect, so please point out what I am missing :)
-Alex
> [This is a partial response to Valerio, whose note came only to me by
> mistake. I expect he'll be sending it out again shortly.]
>
> > >Also, there is the problem of how to correctly restore the
> frame buffer
> > when
> > >some idiot swaps out the video card.
> >
> > probably the system crashes? :-)
>
> crash: v.i. (1) to fail catastrophically in such a way
> as to corrupt user data, (2) a system feature that is
> now obsolete, but was strongly supported by
> Windows, (3) what happens after you come off
> the type of drugs that Windows users must
> take to ward off chronic pain.
>
> Seriously, though, it's an issue. A system works only in the
> cases you can
> anticipate, and then only if you bother.
>