Hello,
I agree with Jonathan,
today graphical resolutions are too big, and there are prohibitive space
(size) and time (performance) implications.
A graphics system must be able to redraw the entire screen and single
windows. A "redraw" routine should be faster than paging, because there is
no interaction with *relatively* slow devices (disks).
Also, a GUI is nice, but it is not always needed, IMO it must remain a
separate add-on component.
I may be wrong, but if you add the display buffer to the checkpoint area later, you'll get it later when the system reboots, so there is no performance optimization in writing the display buffer to the disk to retrieve it later, with respect to "redraw". :-)
valerio
On 27/06/2000 at 07.54 Jonathan S. Shapiro wrote:
>> It is slick to include the display buffer in the checkpoint. We did this
>on
>> the Luna port.
>
>Slick, but it has hideous paging implications. The first time a newline is
>hit in the first terminal window the entire display must be marked copy on
>write.
>
>This trick was feasible on a one megapixel monochrome display. It requires
>too much memory on a modern >megapixel 32-bit color card.
>
>In EROS, the display buffer is outside the checkpoint contract. A decent
>graphics system already needs to know how to issue a "redraw" request in
any
>case. Also, user code is better able to deal with things like "the display
>card got swapped, now what the hell do I do?"
>
>Observation: I may be wrong about this being a good idea, but it's really
>easy to add the display buffer to the checkpoint area later. It's really
>hard to go the other way around and edit the gui/app protocol.