GPS: The general consensus seems to be that the current Tk layer of Xlib emulation is not ideal for some systems. In many cases it's incomplete or buggy. At first I thought writing a new man page that documents the Xlib functions that can be used portably, and those that can't, would be useful. Now I think having a new model for Tk 9.0 would help more than a man page.

These are some problems with the current model (add your own if you want):

1. Lack of true double buffering in X, which results in some flicker with large displays. - GPS
2. The Xlib functions exposed must be used with Tk internals, and thus this makes it more difficult for a user to build/install an extension that provides new widgets or drawing abilities. - GPS
3. Images and the manipulation of them can be unusably slow. - GPS
4. Printing is often done with XGetImage when a postscript subcommand is not available for a widget. This causes problems when inferior windows obscure a region on the screen. - GPS
5. Under Windows OS there is apparently a mismatch of API models that causes many Windows GDI objects to be needlessly created and destroyed. There was a "speedpatch" checked into CVS against an early 8.4Tk that addressed this by clever caching. Would be nice if the worst cases of this could be minimized in a future core version. RT
6. Under Windows, -stipple option for canvas and text is apparently not supported at all. RT
7. Width, height, and depth information should be retained for a Drawable. The problem is that calls like XGetGeometry slow the responsiveness of Tk over a networked display. - GPS

Solutions:

1. [XDBE] AKA X double buffering extension (this is common) - GPS
2. A concise, public API should be designed that is based on input from experts familiar with X, Windows, and Mac OS window and drawing techniques. - GPS
3. unknown
4. For printing a series of pixmaps could be supplied by each widget if needed. This has the advantage of bypassing the XGetImage problem, but forces widgets to fill in a callback function or provide some means to inform others of their drawing. A series of pixmaps is needed in some cases, because the size of a pixmap is limited, and the actual size of the document being displayed may be much larger. - GPS
5. unknown
6. unknown
7. In most cases, Tk could know enough about what the current state is of a Drawable/Pixmap. Perhaps Tk_Drawable, and Tk_Pixmap structures could eventually replace existing uses, and the structure members for the ->width/->height would be updated when the Drawable/Pixmap changes. - GPS

XDBE makes it fairly easy to implement double buffering. For our usage we could have a generic object that contains a ->pixmap member that is used with XCopyArea to copy to the XdbeBackBuffer, before an XdbeSwapBuffers() call. The complexity and the porting of this should be factored out, but I'm not sure how to do so.

Questions:

Comments:

NEM drops a link to TkGS in case it's relevant to this discussion... :)

---