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 classic Mac interface, but unless I am badly
mistaken, it is no longer maintained.) 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.
   1. 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.
   1. 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.

- [D. Richard Hipp], 2004-Oct-16

----