RFC: TkGS: the Tk Graphics System, a Xlib replacement

3 views
Skip to first unread message

Frederic BONNET

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
I'm pleased to announce the first draft specification of TkGS, the Tk
Graphics System. TkGS is a graphics system that aims to replace the
current Xlib emulation layer (XLEL) onto which Tk is implemented on
Windows and MacOS platforms. The XLEL has shown its limits, notably in
term of performance, and TkGS is an attempt to address all the issues
where the XLEL fails to give satisfaction. TkGS also tries to ease the
implementation of future features such as printing support.

You can find the current TkGS specification online at:

http://www.multimania.com/fbonnet/Tcl/TkGS/specs.htm

This is a very early draft, and many sections are yet to be written, but
I'm expecting much feedback from other Tk users, especially extension
writers. I welcome critics, corrections, suggestions, and also
specifications on the missing parts. I hope this project will follow an
Open Source philosophy, and that many people will contribute in all the
different areas (specification and documentation writing,
implementation, advocacy, testing...).

Happy reading!
--
Frédéric BONNET frederi...@ciril.fr
---------------------------------------------------------------
"Theory may inform, but Practice convinces"
George Bain

Nat Pryce

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to

Frederic BONNET wrote:
>
> I'm pleased to announce the first draft specification of TkGS, the Tk
> Graphics System. TkGS is a graphics system that aims to replace the
> current Xlib emulation layer (XLEL) onto which Tk is implemented on
> Windows and MacOS platforms. The XLEL has shown its limits, notably in
> term of performance, and TkGS is an attempt to address all the issues
> where the XLEL fails to give satisfaction. TkGS also tries to ease the
> implementation of future features such as printing support.
>
> You can find the current TkGS specification online at:
>
> http://www.multimania.com/fbonnet/Tcl/TkGS/specs.htm

A nice start. I have a few comments/requests.

* Drawing operations should be directed to a Tk_GC rather than
a Tk_Drawable (ie: the first argument should be a Tk_GC).
Having to explicitly load settings into a Drawable will be
complex, especially if multiple threads are drawing onto the
same drawable, which is possible in Win32.

On systems that need it, it would be trivial to keep track
of the GC that is currently loaded onto a drawable and swap
GCs when necessary without the programmer needing to worry
about it.

* IMHO coordinates should be real numbers.

* It should be possible to specify affine transformations of
the coordinate system. It would be nice if there was a
transform stack (as in OpenGL).

* It would be nice to support antialiasing, or at the very
least alpha channels.

Cheers,
Nat.

--
+------------------------------------------+---------------------+
| Name: Nat Pryce MEng ACGI | Dept. of Computing, |
| Email: n...@doc.ic.ac.uk | Imperial College, |
| Tel: +44 (0)171 594 8394 | 180 Queen's Gate, |
| Fax: +44 (0)171 581 8024 | London SW7 2BZ, |
| WWW: http://www-dse.doc.ic.ac.uk/~np2 | United Kingdom |
+------------------------------------------+---------------------+

Scott Redman

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
Awesome...

My comments, I think you need to mention:

multithreading support (like Tk 8.1)
I18N (UTF-8 support)
no loss of Tk functionality (which I think you are implying)

Are you going to handle buttons using native button widgets, or
draw them with the TkGS code? Same goes for other widgets. (did
I miss this in your spec?)

Looks good.


-- Scott Redman
-- Scriptics Corp.


Frederic BONNET wrote:
>
> I'm pleased to announce the first draft specification of TkGS, the Tk
> Graphics System. TkGS is a graphics system that aims to replace the
> current Xlib emulation layer (XLEL) onto which Tk is implemented on
> Windows and MacOS platforms. The XLEL has shown its limits, notably in
> term of performance, and TkGS is an attempt to address all the issues
> where the XLEL fails to give satisfaction. TkGS also tries to ease the
> implementation of future features such as printing support.
>
> You can find the current TkGS specification online at:
>
> http://www.multimania.com/fbonnet/Tcl/TkGS/specs.htm
>

Frederic BONNET

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
Hi Nat,

Thank you for your quick reply. See my responses below.

Nat Pryce wrote:
> A nice start. I have a few comments/requests.
>
> * Drawing operations should be directed to a Tk_GC rather than
> a Tk_Drawable (ie: the first argument should be a Tk_GC).
> Having to explicitly load settings into a Drawable will be
> complex, especially if multiple threads are drawing onto the
> same drawable, which is possible in Win32.
>
> On systems that need it, it would be trivial to keep track
> of the GC that is currently loaded onto a drawable and swap
> GCs when necessary without the programmer needing to worry
> about it.

IMHO directing the operations to a Tk_GC brings us back to the Xlib model (ie
stateless) which is not well suited on Windows and Mac (state-oriented) for
performance reasons. I think my proposal is an acceptable compromise:
implementing a state-oriented model on top of a stateless system adds very few
overhead. But you're right to mention the threads problem. This could be handled
transparently into the driver: a drawable could use one context for the
different threads. This would avoid collision risks. But it shifts the
difficulty into the driver.
Else I don't see much added complexity in explicit loading of settings versus
the regular XGC allocation/filling/deallocation. It is still possible to store
Tk_GCs and to load them when needed using Tk_GetGC and Tk_SetGC. You can get a
similar behavior with Tk_SetGCValues, but then you lose any benefit of
transparent state storage.

Chosing a state-oriented model over the current stateless model is the key
issue. I think both can be implemented efficiently in term of performance, the
former being easier IMHO. But this choice needs to be made now because it
conditions the whole model. My specification is only a rough draft to initiate
discussion aroud this problem. If a stateless model is chosen, then we could use
a model similar to the dual-ported Tcl_Objects (see the paragraph about colors
below). Tell me your feelings about that.

>
> * IMHO coordinates should be real numbers.
>
> * It should be possible to specify affine transformations of
> the coordinate system. It would be nice if there was a
> transform stack (as in OpenGL).

A transform stack is a bit too high level for TkGS' purpose, but coordinates
systems would be welcome. I think of something close to the Windows API:
specifying mapping between logical and physical coordinates. Note that this
(somewhat) eliminates the need for floating-point coordinates, unless you want
to use sub-pixel precision. TkGS could provide both integer and real APIs:
integers yield better performance because they can be directly useable by the
undelying system, and reals have a better precision (and are also used by the Tk
canvas in its coordinates system).

> * It would be nice to support antialiasing, or at the very
> least alpha channels.

I had these features in mind for a long time. But they would be very costy to
implement on non-supporting hardware if enabled by default. Using a
capability-based system could bring the best performances in all cases. For
example, simple applications would request a standard visual model, whereas
applications needing such advanced features would request them individually.
When they are available, they would be handled by the system. When unavailable,
they could be explicitly emulated if possible, or rejected: antialiasing is
useful but costy on a display, but is useless on a printer. Alpha channels are
quite costy on regular graphics devices, but are a standard feature on
hardware-accelerated OpenGL.

Alpha channels support is the reason why the Tk_Color part is still unspecified.
It could be made of a device-specific and a device-independent part, the former
to cache private structures and the latter to hold parameters in a transparent
manner. See this model as something similar to the dual-ported Tcl_Objects: one
visible part (the string) and one internal representation (integer, lists...)
that is cached for performance purpose but can change depending on the
operation. But maybe this is too heavy for such a simple structure. However the
same principle can be applied to Tk_GCs for example.

See you, Fred

James Ingham

unread,
Apr 14, 1999, 3:00:00 AM4/14/99
to
Scott and Frederic,

>
> Are you going to handle buttons using native button widgets, or
> draw them with the TkGS code? Same goes for other widgets. (did
> I miss this in your spec?)
>

You will need to handle control def'n functions (the Mac language) for
drawing native widgets in some way. This is an issue both on the Mac,
and if we ever want to play nice with GTk and other themeable widget
sets. I am not a big advocate of themeability - it usually results in
someone else's ability to make my application look really ugly - but
the majority do not seem to share my view, so...

Also, you need to handle colors and other components of the GC
symbolically. On the Mac under appearance, for instance, you cannot
query directly for the colors & patterns you should use to draw
standard UI elements. Rather you pass the system a cookie saying: I
want to draw a list header, or highlighted menu item or whatever,
and it sets everything up appropriately. So I have to somehow be able
to store these cookies in the GC and have them override the colors,
patterns, etc. that are stored there.

On the Mac front, I am not near my IM books now, but roughly it goes
like this:

Coordinates:

You have two coordinate systems, global & port local. The global
coordinates are centered at the ULH corner of - if I remember aright -
the monitor that has the menu-bar (though it may be the startup
monitor, I am not really sure.) The other monitors are arranged on a
larger virtual space wherever the user choose to put them in the
Monitors control panel. This can change on the fly. There are
functions that translate between these two coordinate systems, but you
have to set the Port to do translations for that port.

Note: switching ports is a low cost operation on the Mac.

Devices: You are pretty much right, with one little twist: any window
can have more than one Device associated with it. It could be
half on one monitor, and half on another. However, if you are drawing
in true-color mode, and letting QuickDraw do all the dithering for you
(which is what MacTk does currently) then this is fairly transparent.
This actually works quite well for most purposes.

One other point. On the Mac, the Tk side of a window is more
complicated than on the X & Windows side, since there is no subwindow
system on the Macintosh (well, there is with Appearance, but not when
Ray was doing the original design). There was some talk about using
this model for Windows, as well, since using the Windows HWND's for
every widget causes alot of noise. We should decide whether this is a
good idea or not, and if it is, then we should somehow build it into
the specification of the Tk_Window.

Finally, on the Macintosh, setting up Graphics contexts is not all
that time consuming. You grab the current port, which is just setting
a pointer pretty much, and then copy a few colors into the port. I
don't think that caching this is really going to help performance all
that much. On the Mac at least, the majority of the sluggishness is
because the drawing is delayed, rather than done immediately.

I know that Ray Johnson & Scott Stanton have some ideas about how to
let widgets immediatly draw themselves, while still forwarding the
correct events for the bind mechanism. This is sort of orthogonal to
the drawing model, but is an important part of the whole picture.

Jim

--
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham jin...@cygnus.com
Cygnus Solutions Inc.

Paul Duffin

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to Frederic BONNET
Frederic BONNET wrote:
>
> I'm pleased to announce the first draft specification of TkGS, the Tk
> Graphics System. TkGS is a graphics system that aims to replace the
> current Xlib emulation layer (XLEL) onto which Tk is implemented on
> Windows and MacOS platforms. The XLEL has shown its limits, notably in
> term of performance, and TkGS is an attempt to address all the issues
> where the XLEL fails to give satisfaction. TkGS also tries to ease the
> implementation of future features such as printing support.
>
> You can find the current TkGS specification online at:
>
> http://www.multimania.com/fbonnet/Tcl/TkGS/specs.htm
>
> This is a very early draft, and many sections are yet to be written, but
> I'm expecting much feedback from other Tk users, especially extension
> writers. I welcome critics, corrections, suggestions, and also
> specifications on the missing parts. I hope this project will follow an
> Open Source philosophy, and that many people will contribute in all the
> different areas (specification and documentation writing,
> implementation, advocacy, testing...).
>
> Happy reading!

A few comments on your spec which is a great start.

You have two Tk_GetGCValues functions, the second of which should be a
Tk_SetGCValues.

I know that it is not within the scope of what you are trying to do at
the moment but I think that there should be a generic interface to
accessing printers. e.g.
Tk_Printer Tk_GetPrinter (char *name);
Tk_Drawable Tk_GetPrinterDrawable (Tk_Printer printer);

Tcl_Obj *Tk_GetPrinters ();
Tk_Printer Tk_RegisterPrinterDriver
:
:
:

Printers could just be a special type of your device drivers marked as
being a printer.

What about extending it to cover widget creation, e.g. have widget
drivers which provide the basic widgets and have generic ones which
can be used if a native version is not provided. The interface to
the drivers would consist of a generic widget part plus a widget
specific part. It would then be relatively easy to add a C wrapper
around them and a tcl wrapper around that.

Obviously the two extensions that I have suggested (printers and widgets)
could be done in parallel with the TkGS by people with a lot of
experience in these areas.

--
Paul Duffin
DT/6000 Development Email: pdu...@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880 International: +44 1962-816880

Frederic BONNET

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to
Hi Scott,

Scott Redman wrote:
>
> Awesome...

Thank you!

> My comments, I think you need to mention:
>
> multithreading support (like Tk 8.1)

Nat Pryce wrote some comments about that. It seems an important issue
indeed. I think multithreading should be handled by the underlying
drivers for more transparency and ease of use.

> I18N (UTF-8 support)

This is related to text functions. Tk 8.1 already supports I18N, and
since my goal isn't to break things that work :) Migrating the current
procedures to the new model shouldn't be a problem. I've said that the
first TkGS driver would be built on top of the current Tk functions as a
proof of concept (and also as a reference driver, Tk should work the
same with or without TkGS).

> no loss of Tk functionality (which I think you are implying)

It is implied, but maybe I should mention it clearly.

> Are you going to handle buttons using native button widgets, or
> draw them with the TkGS code? Same goes for other widgets. (did
> I miss this in your spec?)

Native widgets won't change, because they (mostly) use native code and
not Xlib. The only changes will occur in every place where Xlib-related
functions or structures are used. For example, 3D borders cache GCs for
performance.
However, Xlib-based widgets will have to be ported (esp. canvas and
text). But the goal of TkGS is to ease the porting effort. In many
cases, simply renaming the structures and functions, and changing one or
two args will work.

It is good to hear comments from people at Scriptics. Do you think this
project conflicts with Scriptics' strategic goals? The goal of TkGS is
to eventually be merged into the Tk core (if Scriptics agree, of
course), that is why the licensing issue is so important. I guess this
is the same situation with Henry Spencer's regexp package, so I don't
think it is a problem because TkGS will be donated to Tk and not used
separately.

Frederic BONNET

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to
Hi James,

James Ingham wrote:
>
> You will need to handle control def'n functions (the Mac language) for
> drawing native widgets in some way. This is an issue both on the Mac,
> and if we ever want to play nice with GTk and other themeable widget
> sets. I am not a big advocate of themeability - it usually results in
> someone else's ability to make my application look really ugly - but
> the majority do not seem to share my view, so...

Themeability can however help getting a consistent _look_ (the _feel is
another issue...) across applications built using different toolkits.
The average user tend to give more importance to the global aspect and
consistency over pure functionality and power, that is why projects like
KDE are so successful, because they bring consistency to Unix platforms
where application traditionally had very different l&f.
Apart from that, TkGS isn't about themeability, but it can help
implementing it into Tk.

> Also, you need to handle colors and other components of the GC
> symbolically. On the Mac under appearance, for instance, you cannot
> query directly for the colors & patterns you should use to draw
> standard UI elements. Rather you pass the system a cookie saying: I
> want to draw a list header, or highlighted menu item or whatever,
> and it sets everything up appropriately. So I have to somehow be able
> to store these cookies in the GC and have them override the colors,
> patterns, etc. that are stored there.

This is exactly the idea behind the opacity of Tk_GCs, versus
Tk_GCValues' transparency. Tk_GCs should be able to store
device-specific info, like system colors. Tk already proposes that kind
of feature through the use of special colors (such as "SystemWindow" on
Windows). This is one of the big concerns of TkGS' future color
management specification.

> On the Mac front, I am not near my IM books now, but roughly it goes
> like this:
>
> Coordinates:
>
> You have two coordinate systems, global & port local. The global
> coordinates are centered at the ULH corner of - if I remember aright -
> the monitor that has the menu-bar (though it may be the startup
> monitor, I am not really sure.) The other monitors are arranged on a
> larger virtual space wherever the user choose to put them in the
> Monitors control panel. This can change on the fly. There are
> functions that translate between these two coordinate systems, but you
> have to set the Port to do translations for that port.

Thank you for the precision, I will include that in the section about
display models. BTW, does local means relative to the local monitor, or
to the window?

> Note: switching ports is a low cost operation on the Mac.

I should add a section about performances. Leo Schubert gave some good
information on Windows GDI performances in his speedpatch. The fact that
graphics operations have a low cost is a very good news, because it
allows more freedom on TkGS model. The only performance issue that
remains concerns (as usual ;) Windows. On that side we are out of luck
because GDI calls are VERY slow. However TkGS device architecture will
open new perspectives such as high-performance DirectX and OpenGL
support. I know one Window port of The GIMP uses GTK under DirectX, and
there is also the GLUT library that provides a Windows-looking toolkit
on top of OpenGL.

> Devices: You are pretty much right, with one little twist: any window
> can have more than one Device associated with it. It could be
> half on one monitor, and half on another. However, if you are drawing
> in true-color mode, and letting QuickDraw do all the dithering for you
> (which is what MacTk does currently) then this is fairly transparent.
> This actually works quite well for most purposes.

Then TkGS' Mac driver should only provide a true-color color model, as
handling several models on one window would be too complicated. I have
to investigate on the Windows 98 side to see if its new multi-monitor
capabilities raise the same issues. Anyway, Windows Tk also uses the
true-color model, as it makes things much easier. I guess the choice of
different color models is a bigger issue on Unix boxes, because they
usually have a 8-bit display (except PC-based Unixes which have more
freedom on their display hardware). Again, TkGS' purpose is not to
remove functionality from Tk, so everything that is supported for now
should be kept.

> One other point. On the Mac, the Tk side of a window is more
> complicated than on the X & Windows side, since there is no subwindow
> system on the Macintosh (well, there is with Appearance, but not when
> Ray was doing the original design). There was some talk about using
> this model for Windows, as well, since using the Windows HWND's for
> every widget causes alot of noise. We should decide whether this is a
> good idea or not, and if it is, then we should somehow build it into
> the specification of the Tk_Window.

Leo Schubert tried (and succeeded) to address this issue on Windows. In
his speedpatch, he proposes a new "flat window" model where Tk windows
now longer use native HWNDs but rather share the same toplevel. It
speeds up things by 400%! By the way, it could also allow transparent
subwindows.
But the windowing aspect is an issues that TkGS doesn't want to address,
its goal is "only" to propose a standard API for drawing things on any
device. As you say, it should concern Tk_Window's specification. I think
progressively removing all the X stuff will help making more suitable
choices.

Anyway, we'll have to solve similar solutions with TkGS for printing
devices. I see paper sheets as similar than a screen where we can define
separate areas (windows). Windows, on the other hand, sees printer
device contexts as one single window. To clarify this position, I had Tk
widget printing in mind when I had this idea. If we want to, say, print
the content of a canvas widget (including subwindows) or print a
toplevel hierarchy (without using image grabs), we need to provide the
same paradigms for screens and paper sheets, so we need to allow
"subwindows" on paper sheets. The problems to solve are the same as with
"flat windows" on a screen, that is, content clipping.

> Finally, on the Macintosh, setting up Graphics contexts is not all
> that time consuming. You grab the current port, which is just setting
> a pointer pretty much, and then copy a few colors into the port. I
> don't think that caching this is really going to help performance all
> that much. On the Mac at least, the majority of the sluggishness is
> because the drawing is delayed, rather than done immediately.
>
> I know that Ray Johnson & Scott Stanton have some ideas about how to
> let widgets immediatly draw themselves, while still forwarding the
> correct events for the bind mechanism. This is sort of orthogonal to
> the drawing model, but is an important part of the whole picture.

Your precisions on Mac performances are interesting. I wonder if such
improvements (immediate drawing) could be handled by the driver in a
transparent manner, or if again it needs to be done at the Tk_Window
level. But this is another story. I think TkGS will make Tk more modular
and will help us improve the overall performance.

Paul Duffin

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to
Frederic BONNET wrote:
>
> I'm pleased to announce the first draft specification of TkGS, the Tk
> Graphics System. TkGS is a graphics system that aims to replace the
> current Xlib emulation layer (XLEL) onto which Tk is implemented on
> Windows and MacOS platforms. The XLEL has shown its limits, notably in
> term of performance, and TkGS is an attempt to address all the issues
> where the XLEL fails to give satisfaction. TkGS also tries to ease the
> implementation of future features such as printing support.
>
> You can find the current TkGS specification online at:
>
> http://www.multimania.com/fbonnet/Tcl/TkGS/specs.htm
>
> This is a very early draft, and many sections are yet to be written, but
> I'm expecting much feedback from other Tk users, especially extension
> writers. I welcome critics, corrections, suggestions, and also
> specifications on the missing parts. I hope this project will follow an
> Open Source philosophy, and that many people will contribute in all the
> different areas (specification and documentation writing,
> implementation, advocacy, testing...).
>
> Happy reading!

Also what about support for images, is that something that is to be left
to Tk, or is it something that you thing could be usefully done, better
done in TkGS.

Alexandre Ferrieux

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to
Paul Duffin wrote:
>
> Frederic BONNET wrote:
> >
> > I'm pleased to announce the first draft specification of TkGS, the Tk
> > Graphics System. TkGS is a graphics system that aims to replace the
> > current Xlib emulation layer (XLEL) onto which Tk is implemented on
> > Windows and MacOS platforms.
>
> Also what about support for images, is that something that is to be left
> to Tk, or is it something that you thing could be usefully done, better
> done in TkGS.

My $0.02: offscreen graphics are obviously a very important tool.
Abstractions, too, are unvaluable. Incidentally, QuickDraw (MacOS)
achieves a good degree of unification/abstraction in this field, since
on-screen, off-screen, PICT-recording and Printers all appear as a
GrafPort. IMHO it would be a great thing to have this spirit in TkGS
(replacing PICT-recording by PostScript generation), because Tcl is all
about abstractions (cf channels).

-Alex

lvi...@cas.org

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to

According to James Ingham <jin...@cygnus.com>:
:Scott and Frederic,
:> Are you going to handle buttons using native button widgets, or

:> draw them with the TkGS code? Same goes for other widgets. (did
:> I miss this in your spec?)
:>
:
:You will need to handle control def'n functions (the Mac language) for
:drawing native widgets in some way. This is an issue both on the Mac,
:and if we ever want to play nice with GTk and other themeable widget
:sets. I am not a big advocate of themeability - it usually results in


This latter (playing nicely with GTk, etc.) seems to me to be a real
payoff as Linux moves away from Tk and towards GTk...

--
<URL: mailto:lvi...@cas.org> Quote: Saving the world before bedtime.
<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

Frederic BONNET

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to
Hi Alex,

Alexandre Ferrieux wrote:
> My $0.02: offscreen graphics are obviously a very important tool.
> Abstractions, too, are unvaluable. Incidentally, QuickDraw (MacOS)
> achieves a good degree of unification/abstraction in this field, since
> on-screen, off-screen, PICT-recording and Printers all appear as a
> GrafPort. IMHO it would be a great thing to have this spirit in TkGS
> (replacing PICT-recording by PostScript generation), because Tcl is all
> about abstractions (cf channels).

That is _exactly_ the philosopy behing TkGS!
BTW, on the list of possible drivers mentioned in the spec, let's add a
Metafile-like recording-playback tool. Using Tk canvas commands as an
output format could allow funny things to be done...

Frederic BONNET

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to
Hi again,

Paul Duffin wrote:
> Also what about support for images, is that something that is to be left
> to Tk, or is it something that you thing could be usefully done, better
> done in TkGS.

All image _display_ related stuff could be handled by TkGS, the current
image structures remaining roughly the same (extensions like Img
register new image types based on this representation). All the image
dithering code could for example migrate to TkGS and be handled very
efficiently. For example, on some Unixes (eg. Linux), the imlib library
provides optimized images and color rendering on any visual type from
mono to true color. On some platforms like the Mac, this can be handled
by the system itself (QuickDraw does the dithering automagically).

Donal K. Fellows

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to
In article <3715BAD9...@ciril.fr>,

Frederic BONNET <frederi...@ciril.fr> wrote:
> Leo Schubert tried (and succeeded) to address this issue on Windows. In
> his speedpatch, he proposes a new "flat window" model where Tk windows
> now longer use native HWNDs but rather share the same toplevel. It
> speeds up things by 400%! By the way, it could also allow transparent
> subwindows.

How do you mean "speeds up things by 400%"? Is it that it makes
things take 80% less time to perform the same operations, allowing you
to get 5 times as many ops in in the same time? Any other option is
against the laws of causality...

Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>

Nat Pryce

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to

Frederic BONNET wrote:
> IMHO directing the operations to a Tk_GC brings us back to the Xlib model (ie
> stateless) which is not well suited on Windows and Mac (state-oriented) for
> performance reasons. I think my proposal is an acceptable compromise:
> implementing a state-oriented model on top of a stateless system adds very few
> overhead. But you're right to mention the threads problem. This could be handled
> transparently into the driver: a drawable could use one context for the
> different threads. This would avoid collision risks. But it shifts the
> difficulty into the driver.

Not at all. The Win32 GDI API uses the concept of a GC (they call it a
DC).
A DC is created for a device (drawable in your terminology) to hold
drawing
state for each client drawing to the device. API functions allow the
client
to modify the drawing state in a DC. Drawing operations are directed to
the DC. Java does the same thing with it's Graphics interface.

The DC on the server holds the current drawing state. The HDC on the
client
is passed to the drawing functions. Drawing operations are performed
"through"
the DC by passing the handle of the DC to the drawing API functions.
The
implementation of these functions on the server knows how to render onto
the
appropriate device using the settings in the DC.

This has the advantages that:
- The client does not have to explicitly load the settings in the
DC onto/off the drawable
- Multiple DCs can be active at any time with different settings.
- It is much easier to make thread-safe

Jochem Huhmann

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to
In article <7f4qup$ooc$1...@srv38s4u.cas.org>,
lvi...@cas.org writes:
LCO>
LCO> According to James Ingham <jin...@cygnus.com>:

>:Scott and Frederic,
>:> Are you going to handle buttons using native button widgets, or
>:> draw them with the TkGS code? Same goes for other widgets. (did
>:> I miss this in your spec?)
>:>
>:
>:You will need to handle control def'n functions (the Mac language) for
>:drawing native widgets in some way. This is an issue both on the Mac,
>:and if we ever want to play nice with GTk and other themeable widget
>:sets. I am not a big advocate of themeability - it usually results in
LCO>
LCO>
LCO> This latter (playing nicely with GTk, etc.) seems to me to be a real
LCO> payoff as Linux moves away from Tk and towards GTk...

This is right. And if I look at Python-Gtk and Python-Gnome, I see a
bright future for them as scripting/GUI combo. Python is extremely
nice and Gnome comes with some real great desktop stuff including
CORBA integration and a lot of widgets, the gnome-canvas seems faster
and even more powerful than the Tk one (with true-type and postscript
and printing support nearly there). It's all a moving target and there
is (almost) no cross-platformness, but still... Tcl/Tk is rapidly
loosing terrain in Linux. And I see a lot of orientation towards
"native look and feel" in regard to Windows but Scriptics seems not to
pay lot attention to this things in Unix/Linux. Under KDE or Gnome a
Tcl/Tk-App looks like a horse under water, simply ignoring font and
color preferences in ~/.kderc and ~/.gtkrc.


Jochem

--
# Jochem Huhmann <j...@gmx.net> Duisburg (Germany)

Chang LI

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to
Frederic BONNET wrote:
>

I hope TkGS is implemented as several .dll rahter than one
big .dll like Tk. The principle is to divide the kernel of Tk
into modules.

--
--------------------------------------------------------------
Chang LI, Neatware
email: cha...@neatware.com
--------------------------------------------------------------

Scott Redman

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to

> It is good to hear comments from people at Scriptics. Do you think this
> project conflicts with Scriptics' strategic goals? The goal of TkGS is
> to eventually be merged into the Tk core (if Scriptics agree, of
> course), that is why the licensing issue is so important. I guess this
> is the same situation with Henry Spencer's regexp package, so I don't
> think it is a problem because TkGS will be donated to Tk and not used
> separately.
>

On the contrary, we have been mulling over rewriting the underlying
code for Windows, but simply don't have the time right now. It would
also be nice to "play nicely" with Gtk and Gnome. It's good to see
that someone has taken the initiative to start this project. And,
if it will help out Tcl Extension writers, then it fits in really
nicely with TEA (Tcl Extension Architecture, for those that don't
know about it).


-- Scott Redman

Scott Redman

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to
Actually, splitting it into multiple DLLs can have a performance
tradeoff. If you're going to use all of the code all of the time,
just stick it into a bigger DLL (IMHO).

I could understand breaking it into pieces so that someone could
rip out portions that they don't need (for, say, Windows CE?).
It should be modular at the code level for this to work, not
necessarily at the DLL level.

How about TkGS being a separate DLL from Tk? Maybe each driver
could be separate as well. I could live with that.

Also, the code needs to support static linking as well (for wrapping
with TclPro Wrapper or freewrap).

-- Scott

mo

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to
Frederic BONNET wrote:
>
> I'm pleased to announce the first draft specification of TkGS, the Tk
> Graphics System. TkGS is a graphics system that aims to replace the
> current Xlib emulation layer (XLEL) onto which Tk is implemented on
> Windows and MacOS platforms. The XLEL has shown its limits, notably in
> term of performance, and TkGS is an attempt to address all the issues
> where the XLEL fails to give satisfaction. TkGS also tries to ease the
> implementation of future features such as printing support.
>
> You can find the current TkGS specification online at:
>
> http://www.multimania.com/fbonnet/Tcl/TkGS/specs.htm
>
> This is a very early draft, and many sections are yet to be written, but
> I'm expecting much feedback from other Tk users, especially extension
> writers. I welcome critics, corrections, suggestions, and also
> specifications on the missing parts. I hope this project will follow an
> Open Source philosophy, and that many people will contribute in all the
> different areas (specification and documentation writing,
> implementation, advocacy, testing...).
>
> Happy reading!
> --
> Frédéric BONNET frederi...@ciril.fr
> ---------------------------------------------------------------
> "Theory may inform, but Practice convinces"
> George Bain


Hi folks, it would be a good idea to look to the ggi project
for the "low level drawing API". GGI would be a good system
to build TkGS on top of. They have already done a lot
of work to define an API that will work directly on top of
hardware as well as on X and just about every other display you
can think of (like SVGA and so on). I am not sure about the status
of ggi on the mac but I have heard some talk about ggi on windows.

Lots of info about ggi can be found at this url
http://www.ggi-project.org/

Mo DeJong
dejong at cs.umn.edu

James Ingham

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to
Frederic,

Thanks for your responses. Looks good, it will be great to move this
forward...

>
> Thank you for the precision, I will include that in the section about
> display models. BTW, does local means relative to the local monitor, or
> to the window?
>

Local to the window.

>
> I should add a section about performances. Leo Schubert gave some good
> information on Windows GDI performances in his speedpatch. The fact that
> graphics operations have a low cost is a very good news, because it
> allows more freedom on TkGS model. The only performance issue that
> remains concerns (as usual ;) Windows. On that side we are out of luck
> because GDI calls are VERY slow. However TkGS device architecture will
> open new perspectives such as high-performance DirectX and OpenGL
> support. I know one Window port of The GIMP uses GTK under DirectX, and
> there is also the GLUT library that provides a Windows-looking toolkit
> on top of OpenGL.
>

Apple has committed to providing a high-performance OpenGL solution
that will be part of the OS. Unfortunately, it is PPC only, so this
would leave our 68K bretheren out in the cold. However, Tk8.0 is
useable on the older Macs, so I am not sure, at this point, how much
this really bothers me.

>
> Then TkGS' Mac driver should only provide a true-color color model, as
> handling several models on one window would be too complicated. I have
> to investigate on the Windows 98 side to see if its new multi-monitor
> capabilities raise the same issues. Anyway, Windows Tk also uses the
> true-color model, as it makes things much easier. I guess the choice of
> different color models is a bigger issue on Unix boxes, because they
> usually have a 8-bit display (except PC-based Unixes which have more
> freedom on their display hardware). Again, TkGS' purpose is not to
> remove functionality from Tk, so everything that is supported for now
> should be kept.

Yes, this is the right choice for the Mac.

>
> Leo Schubert tried (and succeeded) to address this issue on Windows. In
> his speedpatch, he proposes a new "flat window" model where Tk windows
> now longer use native HWNDs but rather share the same toplevel. It
> speeds up things by 400%! By the way, it could also allow transparent
> subwindows.
> But the windowing aspect is an issues that TkGS doesn't want to address,
> its goal is "only" to propose a standard API for drawing things on any
> device. As you say, it should concern Tk_Window's specification. I think
> progressively removing all the X stuff will help making more suitable
> choices.

Ok... This is ANOTHER area where some restructuring is necessary...

>
> > Finally, on the Macintosh, setting up Graphics contexts is not all
> > that time consuming. You grab the current port, which is just setting
> > a pointer pretty much, and then copy a few colors into the port. I
> > don't think that caching this is really going to help performance all
> > that much. On the Mac at least, the majority of the sluggishness is
> > because the drawing is delayed, rather than done immediately.
> >
> > I know that Ray Johnson & Scott Stanton have some ideas about how to
> > let widgets immediatly draw themselves, while still forwarding the
> > correct events for the bind mechanism. This is sort of orthogonal to
> > the drawing model, but is an important part of the whole picture.
>
> Your precisions on Mac performances are interesting. I wonder if such
> improvements (immediate drawing) could be handled by the driver in a
> transparent manner, or if again it needs to be done at the Tk_Window
> level. But this is another story. I think TkGS will make Tk more modular
> and will help us improve the overall performance.
>

Yes this is right.

Thanks for getting this started! Once I get 8.1 out of my hair, I
will be glad to help on this. It should be fun!

Chang LI

unread,
Apr 15, 1999, 3:00:00 AM4/15/99
to
Scott Redman wrote:
>
> Actually, splitting it into multiple DLLs can have a performance
> tradeoff. If you're going to use all of the code all of the time,
> just stick it into a bigger DLL (IMHO).
>

I do not think so. I have noticed that the huge Tk .dll is very
slow to be loaded. It is impossible to use the entire library
for a small script program. For example, some programs never use
the canavs. I am not to say we need to break the .dll according
to the widgets. But multiple .dlls are benefit.

Paul Duffin

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Scott Redman wrote:
>
> Actually, splitting it into multiple DLLs can have a performance
> tradeoff. If you're going to use all of the code all of the time,
> just stick it into a bigger DLL (IMHO).
>
> I could understand breaking it into pieces so that someone could
> rip out portions that they don't need (for, say, Windows CE?).
> It should be modular at the code level for this to work, not
> necessarily at the DLL level.
>

What about making Tk modular at the code level so that it is easy to
build the widgets into seperate DLLs if I want. You would need to do
the following.
1) Don't use internal Tk functions / variables.
2) Each module would have its own initialisation routine of the
same form as normal extensions.
3) Initialisation of the whole should call the individual
routines.

I personally would love to see the Tk widgets split off into seperate
extensions as it would greatly improve the start up time of wish.

> How about TkGS being a separate DLL from Tk? Maybe each driver
> could be separate as well. I could live with that.
>
> Also, the code needs to support static linking as well (for wrapping
> with TclPro Wrapper or freewrap).
>
> -- Scott
>
> Chang LI wrote:
> >
> > Frederic BONNET wrote:
> > >
> >
> > I hope TkGS is implemented as several .dll rahter than one
> > big .dll like Tk. The principle is to divide the kernel of Tk
> > into modules.
> >

> > --
> > --------------------------------------------------------------
> > Chang LI, Neatware
> > email: cha...@neatware.com
> > --------------------------------------------------------------

--

Frederic BONNET

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Hi Nat,

Nat Pryce wrote:
> Not at all. The Win32 GDI API uses the concept of a GC (they call it a
> DC).

Windows' DCs are not the exact counterpart of X GCs. X Separates the
device (the Drawable) from the graphics parameters (the GC). That is why
you need to create GCs and provide both Drawable and GC as parameters. A
GC can apply to any Drawable. On the other hand, Windows' DCs are a
mixture of Drawable and GC: they correspond to a device and have a
drawing state. You can create objects (eg. pen) independently from the
DC, but you have to select then in the DC before drawing anything.
Windows has no distinct notion of GC because it is included in the DC
along with device information. X GCs are independent from any Drawable,
Windows DCs are tied to a device.

In my terminology, a Tk_Drawable is closer to a DC than to a X Drawable.
I chose to call it Tk_Drawable because it makes converting code from
Xlib to TkGS easier IMHO.

> A DC is created for a device (drawable in your terminology) to hold
> drawing
> state for each client drawing to the device. API functions allow the
> client
> to modify the drawing state in a DC. Drawing operations are directed to
> the DC. Java does the same thing with it's Graphics interface.

So we agree, except on the terms! TkGS' terminology is subject to
change, the current spec is still a bit rough. I first thought of using
Tk_GraphicsContext but it was too close to GC, then Tk_DeviceContext but
it was a bit too Windowsish, so I decided to call it Tk_Drawable because
it was closer to the X terms and would make porting code easier (see the
example code in the spec), nothing more. I agree that the exact choice
of the terms is an important point.

See you, Fred

Frederic BONNET

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Hi Scott,

Scott Redman wrote:
> I could understand breaking it into pieces so that someone could
> rip out portions that they don't need (for, say, Windows CE?).

You're right to mention WindowsCE. I think writing a TkGS driver for
WindowsCE will be more feasible than rewriting the Xlib Emulation Layer.

> It should be modular at the code level for this to work, not
> necessarily at the DLL level.

TkGS driver architecture needs to be specified, but I intend to make it
as modular as possible, enabling dynamic drivers.

> How about TkGS being a separate DLL from Tk? Maybe each driver
> could be separate as well. I could live with that.

I first thought of TkGS as a separate DLL used by a widget I'm currently
writing (a super-text widget with CSS-like features), to make
graphics-intensive operations faster. I think TkGS will be first
available as a separate extension. Even if it eventually migrates into
the core, drivers need not be statically linked. Extensions could
dynamically register new drivers the same way they can already register
image formats.

Frederic BONNET

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Hi Donal,

"Donal K. Fellows" wrote:
> How do you mean "speeds up things by 400%"? Is it that it makes
> things take 80% less time to perform the same operations, allowing you
> to get 5 times as many ops in in the same time? Any other option is
> against the laws of causality...

I was quoting Leo. I guess he means up to 5 times faster.

Frederic BONNET

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Hi James,

James Ingham wrote:
> Thanks for getting this started! Once I get 8.1 out of my hair, I
> will be glad to help on this. It should be fun!

Thank you for your contribution!

Looking forward, Fred

Frederic BONNET

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Hi Scott,

Scott Redman wrote:
> On the contrary, we have been mulling over rewriting the underlying
> code for Windows, but simply don't have the time right now. It would
> also be nice to "play nicely" with Gtk and Gnome. It's good to see
> that someone has taken the initiative to start this project. And,
> if it will help out Tcl Extension writers, then it fits in really
> nicely with TEA (Tcl Extension Architecture, for those that don't
> know about it).

That's what I call good news! Now I'm quite confident for the future of
TkGS.

See you, Fred

Frederic BONNET

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Hi Paul,

Paul Duffin wrote:
> A few comments on your spec which is a great start.
>
> You have two Tk_GetGCValues functions, the second of which should be a
> Tk_SetGCValues.

That's a typo, and is corrected now!

> I know that it is not within the scope of what you are trying to do at
> the moment but I think that there should be a generic interface to
> accessing printers. e.g.

[...]


> Printers could just be a special type of your device drivers marked as
> being a printer.

That's exactly the philosophy behind TkGS. We need to define a
capability-based architecture to enable device introspection. Printer
extensions would then "only" need to provide the graphics driver plus a
few access procs like those you mentioned.

> Obviously the two extensions that I have suggested (printers and widgets)
> could be done in parallel with the TkGS by people with a lot of
> experience in these areas.

Michael Schwartz has designed a GDI-specific printer extension. It
provides GDI hooks on the tcl side to create graphics. TkGS will help
make his extension cross-platform.

Donal K. Fellows

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
In article <7f4v4j$pp$1...@nova.revier.com>, Jochem Huhmann <j...@gmx.net> wrote:
> Tcl/Tk is rapidly loosing terrain in Linux. And I see a lot of
> orientation towards "native look and feel" in regard to Windows but
> Scriptics seems not to pay lot attention to this things in
> Unix/Linux. Under KDE or Gnome a Tcl/Tk-App looks like a horse under
> water, simply ignoring font and color preferences in ~/.kderc and
> ~/.gtkrc.

a) What about Motif? There are a lot of Unix/X/Motif systems out
there and LaF integration with them is important.

b) Suppose you have both a .gtkrc and a .kderc with incompatible
LaFs described therein. Which should you honour?

c) (Nah. I won't start *that* flamewar... :^)

Frederic BONNET

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Hi Mo,

mo wrote:
> Hi folks, it would be a good idea to look to the ggi project
> for the "low level drawing API". GGI would be a good system
> to build TkGS on top of. They have already done a lot
> of work to define an API that will work directly on top of
> hardware as well as on X and just about every other display you
> can think of (like SVGA and so on). I am not sure about the status
> of ggi on the mac but I have heard some talk about ggi on windows.
>
> Lots of info about ggi can be found at this url
> http://www.ggi-project.org/

Thank you for the pointer. GGI seems interesting indeed, but it is
rather oriented towards full-screen graphics. There is also a GGI2D
specification, which seems closer to TkGS, and looks like a perfect
candidate for a TkGS driver, as it supports a lot of features such as
anti-aliasing and alpha channels.

Donal K. Fellows

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
In article <3716412A...@spam.com>, mo <n...@spam.com> wrote:
> Hi folks, it would be a good idea to look to the ggi project
> for the "low level drawing API". GGI would be a good system
> to build TkGS on top of.

But only as one possibility amongst many. IOW feel free to do the
work, but don't look surprised if people direct their efforts
elsewhere.

Donal (happy to watch from the sidelines for now...)

Jochem Huhmann

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
In article <7f752n$eek$1...@m1.cs.man.ac.uk>,
fell...@cs.man.ac.uk (Donal K. Fellows) writes:

DKF> In article <7f4v4j$pp$1...@nova.revier.com>, Jochem Huhmann <j...@gmx.net> wrote:
>> Tcl/Tk is rapidly loosing terrain in Linux. And I see a lot of
>> orientation towards "native look and feel" in regard to Windows but
>> Scriptics seems not to pay lot attention to this things in
>> Unix/Linux. Under KDE or Gnome a Tcl/Tk-App looks like a horse under
>> water, simply ignoring font and color preferences in ~/.kderc and
>> ~/.gtkrc.
DKF>
DKF> a) What about Motif? There are a lot of Unix/X/Motif systems out
DKF> there and LaF integration with them is important.

That too, yes. At least there is tk_strictMotif, although setting this
doesn't change even the strange scrollbar feeling of Tk, which is not
motif'ish at all... (I would like to call that a bug actually). Would
also be nice if Tk would grab "*fontlist"-resources, if set.

DKF>
DKF> b) Suppose you have both a .gtkrc and a .kderc with incompatible
DKF> LaFs described therein. Which should you honour?

The last changed one. Or make that depend on a set
tk_strictGtk/tk_strictKde. But you are right, l&f on Unix/X is a can
of worms of its own. Actually one needs some tool-kit independent base
of settings for such stuff (some XML configuration file for fonts and
colors and themes comes to mind here, but that's just a dream). OTOH
if there are settings the user has made (like .kderc or .gtkrc) Tk
should read and honour them as far as possible. That's better than
nothing.

DKF> c) (Nah. I won't start *that* flamewar... :^)

Which flamewar? ;-)

Frederic BONNET

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Hi Nat,

Nat Pryce wrote:
> Not at all. The Win32 GDI API uses the concept of a GC (they call it a
> DC).

Windows' DCs are not the exact counterpart of X GCs. X separates the


device (the Drawable) from the graphics parameters (the GC). That is why
you need to create GCs and provide both Drawable and GC as parameters.

On the other hand, Windows' DCs are a mixture of Drawable and GC: they
correspond to a device and have a drawing state. You can create objects
(eg. pen) independently from the DC, but you have to select then in the
DC before drawing anything. Windows has no distinct notion of GC because

it is included in the DC. Also, I think that DCs are available in
limited resources, especially common DCs (window DCs are only limited by
available memory).

In my terminology, a Tk_Drawable is closer to a DC than to an X
Drawable, because it encapsulates state information.

> A DC is created for a device (drawable in your terminology) to hold
> drawing
> state for each client drawing to the device. API functions allow the
> client
> to modify the drawing state in a DC. Drawing operations are directed to
> the DC. Java does the same thing with it's Graphics interface.

So we agree, except on the terms! TkGS' terminology is subject to
change, the current spec is still a bit rough. I first thought of using

Tk_GraphicsContext, then Tk_DeviceContext but it was a bit too


Windowsish, so I decided to call it Tk_Drawable because it was closer to
the X terms and would make porting code easier (see the example code in
the spec), nothing more. I agree that the exact choice of the terms is
an important point.

See you, Fred

Nat Pryce

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to

Frederic BONNET wrote:
> Nat Pryce wrote:
> > Not at all. The Win32 GDI API uses the concept of a GC (they call it a
> > DC).
>

> Windows' DCs are not the exact counterpart of X GCs. X Separates the


> device (the Drawable) from the graphics parameters (the GC). That is why

> you need to create GCs and provide both Drawable and GC as parameters. A

> GC can apply to any Drawable. On the other hand, Windows' DCs are a


> mixture of Drawable and GC: they correspond to a device and have a
> drawing state. You can create objects (eg. pen) independently from the
> DC, but you have to select then in the DC before drawing anything.

> Windows has no distinct notion of GC because it is included in the DC
> along with device information. X GCs are independent from any Drawable,
> Windows DCs are tied to a device.
>
> In my terminology, a Tk_Drawable is closer to a DC than to a X Drawable.
> I chose to call it Tk_Drawable because it makes converting code from
> Xlib to TkGS easier IMHO.

Gotcha! It's quite a while since I last did any serious X
programming.

Anyway, I still stand by my request. I think it will be hard
to emulate the X11 way of using separate GCs and Drawables in
Win32 because Win32 requires that the client opens a "session"
onto the device to encapsulate state respective to drawing on
that device

Separating state from the drawing handle at the API level will
be inefficient in Win32 because you will either have to keep
creating and destroying DCs or load the entire state into
a fixed DC when the user changes Tk_GC.

OTOH, it is trivial to emulate the Win32 way of doing things
over X11 by representing a Tk_GC as a (Drawable,GC) pair. If
drawing functions operate on Tk_GCs then the X11 driver has
easy access to the Drawable and GC handles.

I don't think this will have an adverse effect on the X11 driver
because (from memory) code typically uses a single GC per
drawing batch. Ie: one creates a GC at the start of a repaint
function, modifies its state as one needs different colours
and then destroys it at the end of the paint function.

Bob Techentin

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Paul Duffin wrote:
>
> I personally would love to see the Tk widgets split off into seperate
> extensions as it would greatly improve the start up time of wish.
>

Just a little food for thought. I looked at my HP/UX build of Tk
(8.0.3+), and sorted object modules according to size. The "top 10"
account for more than a third of the library size:

bytes filename
-------------------------
45276 tkImgPhoto.o
42900 tkCanvas.o
39816 tkUnixWm.o
34284 tkTextDisp.o
33140 tkBind.o
29736 tkMenu.o
28756 tkText.o
27584 tkEntry.o
26136 tkWindow.o
25200 tkGrid.o
25000 tkListbox.o
24864 tkCanvPs.o
22476 tkTextBTree.o
22400 tkCanvArc.o
21872 tkFont.o
21220 tkCanvLine.o
20424 tkCmds.o
19012 tkCanvPoly.o
17092 tkButton.o
15904 tkPack.o

--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 284-2702
Rochester MN, 55905 USA http://www.mayo.edu/sppdg/sppdg_home_page.html

Nat Pryce

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Paul Duffin wrote:
> I personally would love to see the Tk widgets split off into seperate
> extensions as it would greatly improve the start up time of wish.

I think that would have an adverse effect for all but the
smallest scripts. Anything that used many of the widget
types would have to dynamically load a DLL for each widget
rather than a single DLL.

Java takes the use of dynamic loading to the extreme (each
class is dynamically loaded when first used) and it really
hurts its startup times. I have actually ported Java programs
to Tcl to improve performance!

Frederic BONNET

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Hi Nat,

Nat Pryce wrote:


>
> Frederic BONNET wrote:
> > Windows' DCs are not the exact counterpart of X GCs. X Separates the
> > device (the Drawable) from the graphics parameters (the GC). That is why
> > you need to create GCs and provide both Drawable and GC as parameters. A
> > GC can apply to any Drawable. On the other hand, Windows' DCs are a

^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> > mixture of Drawable and GC: they correspond to a device and have a
> > drawing state. You can create objects (eg. pen) independently from the
> > DC, but you have to select then in the DC before drawing anything.
> > Windows has no distinct notion of GC because it is included in the DC
> > along with device information. X GCs are independent from any

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Drawable,
^^^^^^^^

> > Windows DCs are tied to a device.
> >

Ooops! I thought I had cancelled this message in time but apparently not
before you get it :(
There is a small mistake in my above statement: X GCs relates to a
specific drawable (at creation time), but nothing prevent their use on
other drawables. Apart from that, the rest is correct and it doesn't
remove much sense to the argumentation.


> > In my terminology, a Tk_Drawable is closer to a DC than to a X Drawable.
> > I chose to call it Tk_Drawable because it makes converting code from
> > Xlib to TkGS easier IMHO.

You've been heard, I'll rename Tk_Drawable to Tk_GC in the next spec. I
must admit that my choice of terminology was quite confusing.



> Anyway, I still stand by my request. I think it will be hard
> to emulate the X11 way of using separate GCs and Drawables in
> Win32 because Win32 requires that the client opens a "session"
> onto the device to encapsulate state respective to drawing on
> that device

I agree, the original Tk_Drawable (now Tk_GC) was designed in that
purpose: holding system-specific info such as drawable+GC on X and HCD
on Windows.

> Separating state from the drawing handle at the API level will
> be inefficient in Win32 because you will either have to keep
> creating and destroying DCs or load the entire state into
> a fixed DC when the user changes Tk_GC.

That's what is currently done by the Xlib emulation layer. Leo
Schubert's speed patch solved this problem by storing DCs
semi-permanently.

> OTOH, it is trivial to emulate the Win32 way of doing things
> over X11 by representing a Tk_GC as a (Drawable,GC) pair. If
> drawing functions operate on Tk_GCs then the X11 driver has
> easy access to the Drawable and GC handles.
>
> I don't think this will have an adverse effect on the X11 driver
> because (from memory) code typically uses a single GC per
> drawing batch. Ie: one creates a GC at the start of a repaint
> function, modifies its state as one needs different colours
> and then destroys it at the end of the paint function.

You're right. The main argument I used in favor of the rather
state-oriented model was that it solved performance problems on Windows
without shifting them to X or Mac.

DUPERVAL, LAURENT

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Bob Techentin wrote:
>
> Paul Duffin wrote:
> >
> > I personally would love to see the Tk widgets split off into seperate
> > extensions as it would greatly improve the start up time of wish.
> >
>
> Just a little food for thought. I looked at my HP/UX build of Tk
> (8.0.3+), and sorted object modules according to size. The "top 10"
> account for more than a third of the library size:
>

Well... I don't know but if I look at this output, it seems as though at
least the text widget and the canvas widget could be separated, as well
as the Img stuff. Dunno.

L

--
Penguin Power!

Laurent Duperval - CGI
5 Place Ville Marie, Suite 1600 South, Montreal H3B 2G2
Tel: (514) 870-0879 Fax: (514) 391-2212
EMAIL: mailto:laurent....@cgi.ca

DUPERVAL, LAURENT

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to

Frederic BONNET wrote:
>
>
> Thank you for the pointer. GGI seems interesting indeed, but it is
> rather oriented towards full-screen graphics. There is also a GGI2D
> specification, which seems closer to TkGS, and looks like a perfect
> candidate for a TkGS driver, as it supports a lot of features such as
> anti-aliasing and alpha channels.
>

But it looks like it would only be useful for the Unix ports. Not that
*I* mind. :-)

Chang LI

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
Paul Duffin wrote:

> What about making Tk modular at the code level so that it is easy to
> build the widgets into seperate DLLs if I want. You would need to do
> the following.
> 1) Don't use internal Tk functions / variables.
> 2) Each module would have its own initialisation routine of the
> same form as normal extensions.
> 3) Initialisation of the whole should call the individual
> routines.
>

I agree. That will be very useful to add new widgets.
At present there is few info about how to add a new widget.

Scott Redman

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to

> What about making Tk modular at the code level so that it is easy to
> build the widgets into seperate DLLs if I want. You would need to do
> the following.
> 1) Don't use internal Tk functions / variables.
> 2) Each module would have its own initialisation routine of the
> same form as normal extensions.
> 3) Initialisation of the whole should call the individual
> routines.
>

(I'm just brainstorming...)

1. To some degree, you'll need to use Tk functions internally for most
widgets. However, you could use the stub table like other extensions
would (the internal stubs table would be fine, since they should all
be in synch most of the time).

2. Each piece is its own extension...

3. ...loading Tk could do a hidden "package require canvas", etc.
for backwards compatibility.


OK, we have to weigh the benefit of this vs. the overhead of the
initialization and DLL/shared-lib loading. Loading a DLL in Windows
takes time, blocking out the memory, loading the code, resolving
symbols, etc. If loading the code collides with another DLL, it takes
longer (Win32 has a hard-coded load location which the OS overrides
automatically if it collides with another DLL, which is about 99% of
the time). Having one larger DLL makes it faster in this sense.

Should building with a "split" Tk be an option? Now we're talking about
support issues (it works when it's not split, but doesn't work when it
is). Granted, this probably isn't as big of a problem, but it should
at least be pointed out.

-- Scott

Ilya Zakharevich

unread,
Apr 16, 1999, 3:00:00 AM4/16/99
to
[A complimentary Cc of this posting was sent to Frederic BONNET
<frederi...@ciril.fr>],
who wrote in article <37170E02...@ciril.fr>:

> I first thought of TkGS as a separate DLL used by a widget I'm currently
> writing (a super-text widget with CSS-like features),

Did you look on etext widget?

ftp://ftp.math.ohio-state.edu/pub/users/ilya/etext/etext.html

Ilya


David Gravereaux

unread,
Apr 17, 1999, 3:00:00 AM4/17/99
to
I really like this thread.

Scott Redman <red...@scriptics.com> wrote:

> ...

>OK, we have to weigh the benefit of this vs. the overhead of the
>initialization and DLL/shared-lib loading. Loading a DLL in Windows
>takes time, blocking out the memory, loading the code, resolving
>symbols, etc. If loading the code collides with another DLL, it takes
>longer (Win32 has a hard-coded load location which the OS overrides
>automatically if it collides with another DLL, which is about 99% of
>the time). Having one larger DLL makes it faster in this sense.

Set the base address in the DEF files:

LIBRARY tcl81.dll BASE=<Address>
EXPORTS
TclReComp
TclReExec
TclReFree
TclReError
....

where <address> = Some address you like that avoids collisions with
other Tcl run-times.

I think only WinNT has this collision problem. You can even rebase
DLLs after compiling. I have this SDK tool for doing it (lost
somewhere in drives). All NT OS dlls have there base addresses
optimized to avoid collision. Why not have the Tcl run-times do the
same?

For even more speed, you could resolve externals using ordinal
positions, but that's explicit loading rather implicit (done by the OS
at load-time when linked to an import library).

But then again, we got Stubs now, so resolving for exports by name at
load-time is avoided. Not only that, but Stubs can offer extensions
the ability to change internal functions by manipulating the Stub's
table. Once that's implimented, of course.


* David Gravereaux *
Tomahawk Software Group
Mahalo Aloha from Maui, Hawai'i

Roy Terry

unread,
Apr 17, 1999, 3:00:00 AM4/17/99
to
The biggest is 45K. I find it odd even to care about it. Are we fighting the
last war?

Bob Techentin wrote:

> Paul Duffin wrote:
> >
> > I personally would love to see the Tk widgets split off into seperate
> > extensions as it would greatly improve the start up time of wish.
> >
>
> Just a little food for thought. I looked at my HP/UX build of Tk
> (8.0.3+), and sorted object modules according to size. The "top 10"
> account for more than a third of the library size:
>

Donal K. Fellows

unread,
Apr 19, 1999, 3:00:00 AM4/19/99
to
In article <37188D9F...@earthlink.net>,
Roy Terry <royt...@earhlink.net> wrote:
> The biggest [object file in the Tk library on HP/UX] is 45K. I find

> it odd even to care about it. Are we fighting the last war?

Well, it could make quite a difference to people who don't need the
facilities, and in any case, the [text] and [canvas] widgets and the
[image] command are actually fairly large chunks of library which are
split over multiple files. A little analysis on SunOS libs (which are
much smaller for some reason) indicates that the canvas widget takes
(at least - I may have omitted some files from this count) about 12.3%
of the lib, the text widget takes 10.7% and the image code takes 5.6%.

If a great many people don't need the code and it can be autoloaded
fine, why have it in by default?

(Other big lumps are the [bind], [grid] and [wm] commands.)

Donal.

Paul Duffin

unread,
Apr 19, 1999, 3:00:00 AM4/19/99
to
Roy Terry wrote:
>
> The biggest is 45K. I find it odd even to care about it. Are we fighting the
> last war?
>

No, we are just trying to modularise things. One advantage that we would
get by splitting the widgets (and geometry managers) into seperate
loadable modules is that Scriptics would be able to see any holes that
exist in the Tk interface.

Also if I wanted to write a very simple program which did not need
canvas or text or images then I may not want to have to pay the
penalty of loading all of them in.

--

Paul Duffin

unread,
Apr 19, 1999, 3:00:00 AM4/19/99
to
Scott Redman wrote:
>
> > What about making Tk modular at the code level so that it is easy to
> > build the widgets into seperate DLLs if I want. You would need to do
> > the following.
> > 1) Don't use internal Tk functions / variables.
> > 2) Each module would have its own initialisation routine of the
> > same form as normal extensions.
> > 3) Initialisation of the whole should call the individual
> > routines.
> >
>
> (I'm just brainstorming...)
>
> 1. To some degree, you'll need to use Tk functions internally for most
> widgets. However, you could use the stub table like other extensions
> would (the internal stubs table would be fine, since they should all
> be in synch most of the time).
>

If an internal (private) Tk function is needed by a lot of widgets then
there is obviously a hole in the interface which needs to be filled.

> 2. Each piece is its own extension...
>

Of course.

> 3. ...loading Tk could do a hidden "package require canvas", etc.
> for backwards compatibility.
>

Actually you should use the auto_load mechanism to do it as then it
only gets loaded if you need it. Also the packages should be
"tk::canvas" and not just "canvas" to try and eliminate nameclashes.

> OK, we have to weigh the benefit of this vs. the overhead of the
> initialization and DLL/shared-lib loading. Loading a DLL in Windows
> takes time, blocking out the memory, loading the code, resolving
> symbols, etc. If loading the code collides with another DLL, it takes
> longer (Win32 has a hard-coded load location which the OS overrides
> automatically if it collides with another DLL, which is about 99% of
> the time). Having one larger DLL makes it faster in this sense.
>

Unless all of the component DLLs have a different base address.

> Should building with a "split" Tk be an option? Now we're talking about
> support issues (it works when it's not split, but doesn't work when it
> is). Granted, this probably isn't as big of a problem, but it should
> at least be pointed out.
>

I think that the code should be structured so that it is possible to
build them seperately, even if you do not support this.

There are some people who would like seperate libraries and some who
want one executable (ProWrap), it would be much easier to satisfy both
groups if Tk was properly modularised so it was easy to use them how
you want.

Ilya Zakharevich

unread,
Apr 19, 1999, 3:00:00 AM4/19/99
to
[A complimentary Cc of this posting was sent to Bob Techentin
<techenti...@mayo.edu>],
who wrote in article <37173A87...@mayo.edu>:

> Paul Duffin wrote:
> >
> > I personally would love to see the Tk widgets split off into seperate
> > extensions as it would greatly improve the start up time of wish.
> >
>
> Just a little food for thought. I looked at my HP/UX build of Tk
> (8.0.3+), and sorted object modules according to size. The "top 10"
> account for more than a third of the library size:

Perl/Tk is already split into parts. Here is the layout for v800.012
(based on 8.0.3, I think). These are (IIRC) stripped non-debugging
OS/2 DLLs, last two letters of names are just checksums.

8750 BitmapSK.dll
109102 CanvasFQ.dll
18477 EntryND.dll
41517 HListDJ.dll
8234 IOFY.dll
18991 ListboIJ.dll
12338 MenubuYF.dll
14383 NBFramMU.dll
61997 PhotoZV.dll
17966 PixmapAE.dll
16941 ScaleNS.dll
12849 ScrollBU.dll
86572 TextMJ.dll
45103 TixGriUU.dll
524838 TkHX.dll
21037 TListDN.dll
20009 XDR.dll
16428 XlibUO.dll

Ilya

Chang LI

unread,
Apr 19, 1999, 3:00:00 AM4/19/99
to
Ilya Zakharevich wrote:
>
> Perl/Tk is already split into parts. Here is the layout for v800.012
> (based on 8.0.3, I think). These are (IIRC) stripped non-debugging
> OS/2 DLLs, last two letters of names are just checksums.
>

At least the canvas, photo, text can be separated.
What is TkHX? It is still too large.

When we are still arguing if it is good to separate Tk into multiple
.dlls
Perl guys had finished this simple work. I do not know the advantages of
a single big Tk dll.



> 8750 BitmapSK.dll
> 109102 CanvasFQ.dll
> 18477 EntryND.dll
> 41517 HListDJ.dll
> 8234 IOFY.dll
> 18991 ListboIJ.dll
> 12338 MenubuYF.dll
> 14383 NBFramMU.dll
> 61997 PhotoZV.dll
> 17966 PixmapAE.dll
> 16941 ScaleNS.dll
> 12849 ScrollBU.dll
> 86572 TextMJ.dll
> 45103 TixGriUU.dll
> 524838 TkHX.dll
> 21037 TListDN.dll
> 20009 XDR.dll
> 16428 XlibUO.dll
>
> Ilya

--

Frederic BONNET

unread,
Apr 20, 1999, 3:00:00 AM4/20/99
to Ilya Zakharevich
Hi Ilya,

Ilya Zakharevich wrote:
> > I first thought of TkGS as a separate DLL used by a widget I'm currently
> > writing (a super-text widget with CSS-like features),
>
> Did you look on etext widget?
>
> ftp://ftp.math.ohio-state.edu/pub/users/ilya/etext/etext.html

Yes, and the block model you designed was quite close to what I was
looking for. However, it seemed to me that implementing the many text
options needed to implement the CSS1+CSS2 model on top of the current
(e)text (and I don't even mention correcting "features" such as per-line
scrolling vs. per-pixel) would take longer than re-implementing a whole
new widget on a clean basis. And indeed, it took be about 3 month
part-time (about 2 hours a day on my free time) to implement a quite
useable widget, which I intend to be the front-end for a medical CD-ROM.

If you want, I can send you a copy with some explanation. I don't think
it's mature for a public release, though (it still needs some work on
bindings).

Ilya Zakharevich

unread,
Apr 20, 1999, 3:00:00 AM4/20/99
to
[A complimentary Cc of this posting was sent to Chang LI
<cha...@neatware.com>],
who wrote in article <371B64...@neatware.com>:

> > Perl/Tk is already split into parts. Here is the layout for v800.012
> > (based on 8.0.3, I think). These are (IIRC) stripped non-debugging
> > OS/2 DLLs, last two letters of names are just checksums.

> At least the canvas, photo, text can be separated.
> What is TkHX? It is still too large.

This is the Tk core. No widgets, just the API to write widgets in.

Donal K. Fellows

unread,
Apr 21, 1999, 3:00:00 AM4/21/99
to
In article <7fipm3$dk6$1...@mathserv.mps.ohio-state.edu>,
Ilya Zakharevich <il...@math.ohio-state.edu> wrote:
> Chang LI <cha...@neatware.com>

>> At least the canvas, photo, text can be separated. What is TkHX?
>> It is still too large.
>
> This is the Tk core. No widgets, just the API to write widgets in.

It sounds like it includes the geometry managers though. Mind you,
I'd suspect that there isn't really much point in excluding them,
since any non-trivial app is likely to use both [grid] and [pack] and
may well even use [place]. So there isn't any point in excluding
them.

I think that {,check,menu,radio}buttons, labels, frames and toplevels
are also included. You need toplevels anyway (for .) and frames are
the same code.

Tk has a lot of support machinery that is required virtually whatever
you do (events, resources, colours, fonts, selections, option manager,
etc.) and factoring that out into a separate lib would just be
pointless.

From the list given, it sounds like the only thing that could be
factored out of the core (as I believe it to be) would be the
little-used [message] widget. Indeed, if it can be sort-of
implemented using another widget, I'd recommend getting rid of it
completely (replacing with a wrapper script instead?)

Ilya Zakharevich

unread,
Apr 21, 1999, 3:00:00 AM4/21/99
to
[A complimentary Cc of this posting was sent to Donal K. Fellows
<fell...@cs.man.ac.uk>],
who wrote in article <7fk3aj$o5d$1...@m1.cs.man.ac.uk>:

> > This is the Tk core. No widgets, just the API to write widgets in.
>
> It sounds like it includes the geometry managers though. Mind you,
> I'd suspect that there isn't really much point in excluding them,
> since any non-trivial app is likely to use both [grid] and [pack] and
> may well even use [place]. So there isn't any point in excluding
> them.

In fact it is an interesting point: most simple apps will *not* use
both pack and grids (and if they are not simple, then the memory
overhead of splitting is not that important). So probably splitting
them out might be beneficial too. You may want to talk with Nick
Ing-Simmons about this (ni...@ni-s.u-net.com).

> I think that {,check,menu,radio}buttons, labels, frames and toplevels
> are also included. You need toplevels anyway (for .) and frames are
> the same code.

I would think that Perl/Tk has no . - what would one need it for? But
splitting out *small* frequently-used things does not look very much
useful indeed.

Ilya

Scott Redman

unread,
Apr 21, 1999, 3:00:00 AM4/21/99
to
> > It sounds like it includes the geometry managers though. Mind you,
> > I'd suspect that there isn't really much point in excluding them,
> > since any non-trivial app is likely to use both [grid] and [pack] and
> > may well even use [place]. So there isn't any point in excluding
> > them.
>
> In fact it is an interesting point: most simple apps will *not* use
> both pack and grids (and if they are not simple, then the memory
> overhead of splitting is not that important). So probably splitting
> them out might be beneficial too. You may want to talk with Nick
> Ing-Simmons about this (ni...@ni-s.u-net.com).

Actually, a lot of simple apps DO use both. But, if Tk is going
to be split, it would make sense to split the different geom. managers
out into different pieces.


> > I think that {,check,menu,radio}buttons, labels, frames and toplevels
> > are also included. You need toplevels anyway (for .) and frames are
> > the same code.
>
> I would think that Perl/Tk has no . - what would one need it for? But
> splitting out *small* frequently-used things does not look very much
> useful indeed.

Backwards compatibility.

-- Scott

Donal K. Fellows

unread,
Apr 22, 1999, 3:00:00 AM4/22/99
to
In article <371E49D1...@scriptics.com>,
Scott Redman <red...@scriptics.com> wrote:
> Actually, a lot of simple apps DO use both [grid and pack]. But, if

> Tk is going to be split, it would make sense to split the different
> geom. managers out into different pieces.

I'm not sure. If we go to a *really* simple app that only uses one
GM, then there is still no particular guarantee which one will be
used. I for one prefer to use grid normally for any script with a
lifetime of more than a couple of minutes (i.e. if I type it into a
file...)

[ attribution lost - someone at Ohio State? ]


>> I would think that Perl/Tk has no . - what would one need it for? But
>> splitting out *small* frequently-used things does not look very much
>> useful indeed.
>
> Backwards compatibility.

Perl/Tk will either have . or some equivalent (the name isn't the
point) since it is the root of the window tree - something you *must*
have. And (virtually) every application will want have at least one
toplevel to provide it with somewhere on the screen to call its own...

Ilya Zakharevich

unread,
Apr 22, 1999, 3:00:00 AM4/22/99
to
[A complimentary Cc of this posting was sent to Donal K. Fellows
<fell...@cs.man.ac.uk>],
who wrote in article <7fmqc5$71b$1...@m1.cs.man.ac.uk>:

> >> I would think that Perl/Tk has no . - what would one need it for? But
> >> splitting out *small* frequently-used things does not look very much
> >> useful indeed.
> >
> > Backwards compatibility.
>
> Perl/Tk will either have . or some equivalent (the name isn't the
> point) since it is the root of the window tree - something you *must*
> have.

Perl/Tk has no root window. Windows of Perl/Tk have no (user-visible)
names (probably there is some API to get what is name in TCL/Tk,
something like

print $window->tcl_name;

but I stressed my imagination, and cannot imagine why would one want this.

> And (virtually) every application will want have at least one
> toplevel to provide it with somewhere on the screen to call its own...

If you need a toplevel marked as a main window, you create it:

my $mw = MainWindow->new(...);

You can have an arbitrary number of them, or none at all (if you use
Tk for something else, such as printing out the current selection).
MainLoop() terminates when there is no MainWindow left.

Ilya

Reply all
Reply to author
Forward
0 new messages