Virtual Framebuffer

The talk by Steve Landers on Klant at the Eleventh Annual Tcl/Tk Conference inspired the following idea:

We really have three different editions of Tk, one for each of the major graphics rendering engines. Though they are not called this, I'll refer to these three editions as tk-x11, tk-win32, and tk-aqua. (There was once a 4th edition, tk-mac, for the MacOS classic interface, but its support ended with 8.5.) I propose adding a new edition of tk which I will call tk-vfb. The "vfb" stands for "virtual framebuffer".

The idea of tk-vfb is that instead of connecting to a graphics engine for doing display rendering, tk-vfb would malloc for a big chunk of memory and render directly into that memory instead of onto some display device. This is similar in concept to Xvfb.

Uses:

1. People sometimes want to make use of Tk features such as image without having to connect to a graphical display; see, for example, "Image manipulation without Tk". tk-vfb would provide that. Donal Fellows is often heard requesting such a capability.
2. By combining tk-vfb with a VNC server extension such as TclRFB, one can construct a thin-client Tk application where the main program runs on a headless server but the graphics display appears on a remote terminal running a VNC client. This gives you the functionality of Klant in a single process and without having to work lots of magic with Xvnc in -inetd mode.
3. New tests could be added to the Tk regression test suite that read back raw bytes from the frame buffer and verify that the correct rendering has occurred.

Implementation

Xvfb could perhaps be used as the basis for the implementation of tk-vfb. Xvfb normally runs in a separate process from the application. Xlib routines serialize requests and send them to the Xvfb server where they are deserialized and acted upon. It seems like it would not be too hard to modify Xvfb so that it omitted the deserialization of the X11 protocol and replaced that code with an Xlib interface into the rendering engine.

The size of the frame buffer would be the size of the main window, ".". Other toplevel windows could either be given their own framebuffers, or they could be superimposed on top of the main window. If the former, a specialized VNC client capable of handling multiple screens would be needed to display the result. If the latter, some sort of window management functionality would need to be added to draw the window frame around the toplevels. The window manager functionality in the second approach could perhaps be implemented as Tcl callbacks [notice GPS' work in this area].

- D. Richard Hipp, 2004-Oct-16

CL has a great appetite for the benefits described above--with which I agree--and mourns the apparent demise of TkGS. I suspect, by the way, that the regression-test opportunity still would depend on local installation of fonts, with all the complications that implies. Ah, well; fonts are in need of rework, anyway ...

Richard, it strikes me that such an implementation also offers the advantage of driving a not-virtual-at-all framebuffer. That is, if I understand the description, it gives us Tk on framebuffered hosts, even if they lack X, or their X impairs performance.

rdt : Ooh! I sure like this idea. I would like to be able to install using a tcl/tk installer without having all of X needed during the installation. What is the status of this and from where can it be obtained?

Rather than malloc'ing a big chunk of memory to render the widgets, one could make use of the server aspects of TclRFB directly. Steve Landers really didn't speak about the RFB server functionality available in TclRFB, but it is there. Using the RFB protocol, a vfb-enabled application would render each widget upon demand from the RFB client viewer or as each widget is changed by the application. A very basic example of this is the rfbcounter.tcl application that comes with the TclRFB distribution. I would be possible to implement a interface layer between an application an TclRFB to create a Tk-like virtual widget set that would be visualized through an RFB client viewer. The amount of resources required by virtual widget set would be the virtual widget library plus any virtual widgets that are created by the application.

- Mac Cody December 9, 2004