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):
- Lack of true double buffering in X, which results in some flicker with large displays.
- 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.
- Images and the manipulation of them can be unusably slow.
- 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.
Solutions:
- XDBE AKA X double buffering extension (this is common)
- 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.
- unknown
- 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.
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: