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:
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