An Architectural Overview of the Fresco Project

The Fresco display server consists of a large data structure called a scene graph in which an abstract representation of the image you see on the screen is stored. The scene graph is constructed at runtime by client processes connecting to the display server and asking for new objects to be built and attached to the graph. Clients make such requests through a distributed object technology called CORBA. Once objects are attached to the scene graph, a user interacts directly with them in the display server process, occasionally sending updates back to client processes to inform them of some change they might be interested in.

This approach has a number of important features:

• a user can interact with objects in the scene graph with little to no communication with a client taking place. thus it is very "network friendly", and comparatively fast
• objects in the scene graph are partly insulated from a client process, meaning that the client does not need to know many specific details about them such as look and feel, device resolution, method of drawing, or implementation language
• the structure of the scene graph can be reasonably rich without incurring communication or processing load on the client. thus for example a shared client on a networked compute server does not need to spend CPU or network time rendering images to be sent to the display server
• it is easier to adapt to hardware accelerated drawing environments, since the majority of drawing commands are issued without knowledge of the client

The acknowledged disadvantage of this approach is that by moving a larger quantity of code into a single process, there is a greater chance that the display server will crash. This problem is mitigated (though not eliminated) in Fresco by the following factors:

• Fresco adopts most of its design and code from a X11 toolkit by the same name. This toolkit featured extremly aggressive internal code reuse, as does the Fresco display server today. Thus there is actually far less code driving the display than one at first would imagine
• Fresco happily runs as a non-privileged user process on systems (such as Linux framebuffer) which support such access to video hardware. Thus a crashed display server does not mean a complete system failure the way it does in, for example, the X window system or windows GDI
• The separation of display logic from application logic encouraged by our approach makes it easier to write applications which are capable of reconnecting to a display server and rebuilding a view of their data. Thus a crashed display server does not necessarily mean crashed applications

Further reading

Hopefully this has given you a taste for what Fresco is all about. We recommend you move on over to the documentation page if you want to learn more.