Re: fltk and GL (WAS: Unix/Win GUI re-evaluation)

[Stan Shebs <shebs@cygnus.com>]

   Date: Thu, 10 Jun 1999 21:33:25 +0200 (MET DST)
   From: Jan Jona Javorsek <jan.javorsek@guest.arnes.si>

   True. Same goes for gtk. In fact it would be interesting to see if the
   problems with tk port could be fixed simply by not using tk for the game
   canvas at all. (tk looks nice and is functional. I adore tear-off menus,
   for example.) GL is not to be dropped wihtout any thought, though.

The tk port has a "custom widget" for the map, and it uses a combination
of Tk_* calls and X* calls.  Most of the Tk_* calls are wrappers for
Xlib calls, usually adding something like ref counts or memory management
that tcl needs.  So tk drawing is not directly implicated in any slowdowns;
redrawing a big window takes about the same amount of time as under Xaw,
if the tk interface's new features (like the fuzzed-out edges) aren't
used.

The knotty performance problem actually stems from tk's event handling
model.  Every screen update, even the ones that do the "marching ants"
for the current unit, goes through tcl's event loop, which entails
execution of tcl code bits and other deep thoughts.  This is pretty
fundamental to how tcl works, and there's not much prospect of
changing it, at least according to my personal tcl consultant
(Jim Ingham :-) ).  So to speed that up, one would have to bypass
the tcl event loop somehow, which is probably possible, but rather
dangerous; if you lost any of the events for the other widgets,
things would get really confused.  So that's a last resort.

							Stan