"booster-label" - why does it work such way? (8.4.12 on Debian Etch)
ZB
noticed a strange - but very interesting thing. Take a look at the following
script:
================== cut =============
#! /bin/sh
# the next line restarts using wish \
exec wish "$0" "$@"
#label .foo
for {set ii 0} {$ii < 20} {incr ii} {
label .label$ii -text "label #$ii" -font "Helvetica 10"
pack .label$ii
puts $ii
}
================== cut =============
There is noticeable difference in filling the output window (look at the
puts counter speed), when you either uncomment the #label .foo line - or
delete the `-font "Helvetica 10" ' parameter from label definition.
What do you think? Why using font option in label definition makes it so
slow - and even so: why adding senseless looking line fixes the whole thing?
It doesn't have to be a label; you can replace it with f.e. "scale .foo"
definition - the result is the same. The presence of such line makes
building of the output window over 10x faster, like there weren't font
option added.
--
ZB
Bryan Oakley
> Hallo,
>
> noticed a strange - but very interesting thing. Take a look at the following
> script:
>
> ================== cut =============
> #! /bin/sh
> # the next line restarts using wish \
> exec wish "$0" "$@"
>
> #label .foo
> for {set ii 0} {$ii < 20} {incr ii} {
> label .label$ii -text "label #$ii" -font "Helvetica 10"
> pack .label$ii
> puts $ii
> }
> ================== cut =============
>
> There is noticeable difference in filling the output window (look at the
> puts counter speed), when you either uncomment the #label .foo line - or
> delete the `-font "Helvetica 10" ' parameter from label definition.
Do you have really slow hardware? Or maybe you're running a *nix version
with an X11 font server on a different machine? The above code happens
in the blink of an eye on my windows box. When I time the code on my
box, both with and without the "label .foo", [time] reports it takes 0
microseconds (read: too fast to measure)
--
Bryan Oakley
http://www.tclscripting.com
ZB
>> There is noticeable difference in filling the output window (look at the
>> puts counter speed), when you either uncomment the #label .foo line - or
>> delete the `-font "Helvetica 10" ' parameter from label definition.
>
> Do you have really slow hardware?
It's Pentium III 550.
> Or maybe you're running a *nix version
> with an X11 font server on a different machine?
No.
> The above code happens
> in the blink of an eye on my windows box. When I time the code on my
> box, both with and without the "label .foo", [time] reports it takes 0
> microseconds (read: too fast to measure)
OK, that's for description of your hardware - it's really wonderful,
congratulations - what about my question?
--
ZB
ZB
> When I time the code on my box, both with and without the "label .foo",
> [time] reports it takes 0 microseconds (read: too fast to measure)
OK, for those using the hardware as slow as mine:
- wit `-font "Helvetica 10"' option: 28792.5 microseconds per iteration
(it was set for 20 iterations)
- without `-font "Helvetica 10"' option: 2383.8 microseconds per iteration
- with font option, and "label .foo" uncommented: 2252.65 microseconds per
iteration
- without font option, and with "label .foo" uncommented: 923.65
microseconds per iteration
Why is that?
Code has been modified:
============================ cut ==========================
#label .foo
set ii 0
set report [time {
label .label$ii -text "label #$ii" -font "Helvetica 10"
pack .label$ii
puts $ii
incr ii
} 20]
puts $report
--
ZB
Mark Janssen
> Dnia 27.08.2007 Bryan Oakley <oak...@bardo.clearlight.com> napisa³/a:
Random guess (as my hardware is too fast to reproduce this problem as
well), do you have the Helvetica font installed on your box? And do
you see a difference in behaviour when using:
label .label$ii -text "label #$ii" -font "10"
Also could you time if you time the first label .foo, how long does
that take?
Mark
ZB
> Random guess (as my hardware is too fast to reproduce this problem as
> well), do you have the Helvetica font installed on your box?
Every application in my system offers - among others - "helvetica" font to
choose from (GIMP, Tcl/Tk-based apps and so on...), so I can make assumption
(I hope), it's installed already?
> And do you see a difference in behaviour when using:
>
> label .label$ii -text "label #$ii" -font "10"
You mean: with "label .foo" commented out, and without setting font family
(just size)? Result: 31156.9 microseconds per iteration (when 20 iterations).
> Also could you time if you time the first label .foo, how long does
> that take?
Did you mean: "set aaa [time {label .foo} 1] ; puts $aaa"?
If so - the result is: 32102 microseconds per iteration
Yes, it adds delay - but it doesn't matter. When I set in the main loop
f.e. 200 iterations, it says: "1063.86 microseconds per iteration" (without
"label .foo": 26712.76 microseconds per iteration).
It seems, that such "senseless" definition is a real graphics accelerator.
But - as I asked twice already - _why_ is that?
--
ZB
Mark Janssen
> Dnia 27.08.2007 Mark Janssen <mpc.jans...@gmail.com> napisa³/a:
If I knew why I would have told you, I was just trying to get more
info. One thing that could have happened was that the first label
command incurred a big overhead for some reason skewing your
measurement in the loop. I guess that is not the case (which seems
confirmed by the 200 loop measurement).
Also removing the font family makes no differences so that seems to
indicate the font searching algoritm is not to blame.
I am not familiar enough with the internals of Tk to have any other
ideas to rule out.
Mark
ZB
> If I knew why I would have told you, I was just trying to get more
> info. [..]
> I am not familiar enough with the internals of Tk to have any other
> ideas to rule out.
I think, it can be valuable to find out, what's going on - perhaps I
encountered a bug in Tk library, which can be fixed, making graphics output
(in some specific situations? always?) faster.
As you can see - the difference can be just dramatic (over 25 times faster!).
--
ZB
Joe English
>noticed a strange - but very interesting thing. Take a look at the following
>
>There is noticeable difference in filling the output window (look at the
>puts counter speed), when you either uncomment the #label .foo line - or
>delete the `-font "Helvetica 10" ' parameter from label definition.
>
>What do you think? Why using font option in label definition makes it so
>slow - and even so: why adding senseless looking line fixes the whole thing?
I get similar results here (also on X11). Here's my best guess
as to what's going on:
Loading fonts on X11 is _expensive_. Tk reads a ton of
data from the X server for each font; and the X server
may in turn need to load it from a font server (few modern
X11 systems still use XFS, though, so that probably isn't
happening here. It's still expensive though).
Tk maintains a cache of all the fonts currently in use,
so only the first widget to use a particular font takes
a performance hit; future references to that font will
be quick.
However, Tk also removes fonts from the cache when the
last reference to them goes away. So if a program uses
a font, stops using it, then starts using it again, it
takes a performance hit the second time too.
Now here:
label .label$ii -text "label #$ii" -font {Helvetica 10}
Tk first creates the widget ".label$ii" and initializes
it with default values, including "-font {Helvetica -12 bold}"
(or something different if Label.Font has been overridden
in the X resource database). If this is the first widget
to use {Helvetica -12 bold}, it's expensive, otherwise cheap.
Next it applies all the configuration options, including
"-font {Helvetica 10}". If this is the first widget to
use that font, it's also expensive. Moreover, if this is
the _last_ widget to use {Helvetica -12 bold}, _that_ font
is removed from the cache, and the next widget you construct
will take a performance hit again.
Simpler way to reproduce:
$ wish
% time { destroy [label .l] } 100
2511 microseconds per iteration
% button .b
.b
% time { destroy [label .l] } 100
45 microseconds per iteration
% destroy .b
% time { destroy [label .l] } 100
2655 microseconds per iteration
--Joe English
[ Original demo script follows : ]
Mark Janssen
Is this behaviour the same in 8.5? The effect seems to be much less
pronounced on 8.5. Although that's on windows where this probably
works completely different. Also it seems ineffecient to load a font
(on widget creation) and delete it again straight away (on configuring
the specified font) Would it be possible to only load the font that's
actually specified (or be less aggressive in deleting it)?
Mark
ZB
> I get similar results here (also on X11). Here's my best guess
> as to what's going on:
> [..]
> Tk maintains a cache of all the fonts currently in use,
> so only the first widget to use a particular font takes
> a performance hit; future references to that font will
> be quick.
I'm sure, you know Tcl/Tk internals much better, than I know - but I'm afraid,
you're wrong. Why? The results for different numbers of iterations (a line
"label .foo" commented out == "no `acceleration' "):
- 20 iterations = 27871.95 microseconds per iteration
- 200 iterations = 26866.875 microseconds per iteration
- 2000 iterations = 26766.9595 microseconds per iteration
See? If I properly understand it, "time" gives average time of iteration.
So, despite the font has been used already at first iteration - the average
time stays about the same.
Besides: as we found out already, it's not font family, which makes a problem
- just setting the size (or perhaps just "dealing with font" at all?).
Another thing: even, when I remove the option "-font Helvetica 10" - there's
still a little difference depending on that "label .foo" line:
- 2000 iterations without the line: 1033.953 microseconds per iteration
- 2000 iterations with the line: 1003.5365 microseconds per iteration
- 200 iterations without the line: 1017.49 microseconds per iteration
- 200 iterations with the line: 877.415 microseconds per iteration
- 20 iterations without the line: 2380.95 microseconds per iteration
- 20 iterations with the line: 844.85 microseconds per iteration
Pay attention, that the latter is even more important, because rarely one
need to make the graphics using thousands of iterations.
Although the difference is not as dramatic, as the font-caused problem -
it's still here.
--
ZB
Gerald W. Lester
What are the results if outside of the loop he uses the font command to
create a named font and that named font in the label commands?
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Gerald W. Lester
Can you please post the code used to make the above outputs.
Mark Janssen
> Dnia 27.08.2007 Joe English <jengl...@flightlab.com> napisa³/a:
You seem to fail to understand exactly what is happening. The default
font gets loaded and unloaded on each and every iteration of the
loop.
e.g.
label .l -font "Helvetica 10"
- default font gets loaded for .l
- Helvetica 10 is configured for .l
- default font has no more widgets using it so is unloaded
- repeat
The small difference you see without the font line is because of the
overhead of loading the default font for the first time (which is why
it decreases as the number of iterations increases)
So the first label command on loop loads the default font (slow)
The others use the already loaded font (fast)
So the more others you have the smaller the contribution of the first
loop to the average.
So
1) Don't call people wrong when they explain what is happening and you
misunderstand.
2) Know what you measure.
Mark
ZB
Newsserver of my provider sucks - some of the posts are missing, and I can
see them only on Google Group. So I'm answering in such way:
> What are the results if outside of the loop he uses the font command to
> create a named font and that named font in the label commands?
I you mean something like:
font create myFont -family Helvetica -size 10 -weight normal
and then use:
label .label$ii -text "label #$ii" -font myFont
...I can't see any difference. Timings are still the same.
> Can you please post the code used to make the above outputs.
It's still the same:
--------------------------- cut ---------------------------
#! /bin/sh
# the next line restarts using wish \
exec wish "$0" "$@"
#set aaa [time {label .foo} 1]
set ii 0
set report [time {
label .label$ii -text "label #$ii" -font "Helvetica 10"
pack .label$ii
puts $ii
incr ii
} 200]
puts $report
#puts $aaa
-------------------------- cut ------------------------
Just try to remove comment from beginning of the line: #set aaa [time...
- you'll see the difference (or try to remove `-font "Helvetica 10" ').
--
ZB
ZB
>> - 20 iterations = 27871.95 microseconds per iteration
>> - 200 iterations = 26866.875 microseconds per iteration
>> - 2000 iterations = 26766.9595 microseconds per iteration
[..]
> You seem to fail to understand exactly what is happening. The default
> font gets loaded and unloaded on each and every iteration of the
> loop.
>
> e.g.
> label .l -font "Helvetica 10"
> - default font gets loaded for .l
> - Helvetica 10 is configured for .l
> - default font has no more widgets using it so is unloaded
> - repeat
Although the results pasted above SEEMS to be kind of confirmation - it
doesn't explain the influence of the "label .foo" line, which isn't dealing
with any fonts at all(!) - and _THIS_ is the reason, why I think, that Joe's
explanation... can be wrong (if you prefer "light version").
A ".foo" label isn't then used anywhere at all in the script!
> The small difference you see without the font line is because of the
> overhead of loading the default font for the first time (which is why
> it decreases as the number of iterations increases)
Possible.
> So the first label command on loop loads the default font (slow)
> The others use the already loaded font (fast)
> So the more others you have the smaller the contribution of the first
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> loop to the average.
^^^^^^^^^^^^^^^^^^^ ???
...so either the results given above are completely contrary to your guess -
or your guess isn't based on the script I've pasted for comparison purposes.
In the latter case we're talking about two different scripts, and in such way
there will be no conclusion.
> So
> 1) Don't call people wrong when they explain what is happening and you
> misunderstand.
Sorry: if I've got a feeling, that someone's wrong, I'm writing something
like: "I'm afraid, you're wrong"; I'm calling this: "a discussion". And
could you forgive me, if I won't ask you for permission first - will you?
> 2) Know what you measure.
You're right, there's a need to. And once again: did you read the results,
I've pasted (above)?
--
ZB
Mark Janssen
> Dnia 27.08.2007 Mark Janssen <mpc.jans...@gmail.com> napisa³/a:
>
>
>
Ok apologies for maybe sounding a bit too harsh, so of to the
discussion.
The reason the label .foo is making a difference is because the
label .foo is keeping a reference to the default font even though it
is not displayed. This means that when you create the other labels the
default font is still there when they are created (no overhead) and
will not be removed when the font changes (the .foo label still has a
reference so no overhead)
That clears up why the label .foo makes a difference.
When the reference count of the default font (lets call that x) is 0
it gets unloaded when it becomes 1 it gets loaded.
without .foo
label .l -font y
- create label with default font (x->1 -> load font)
- change font to y (x -> 0 -> unload)
repeat
with .foo
label .foo (x->1 -> load font)
label .l -font y
- create label with default font (x->2 font already loaded)
- change font to y (x -> 1 -> font remains loaded)
repeat
Secondly the results I was refering to were these:
- 2000 iterations without the line: 1033.953 microseconds per
iteration
- 2000 iterations with the line: 1003.5365 microseconds per iteration
- 200 iterations without the line: 1017.49 microseconds per iteration
- 200 iterations with the line: 877.415 microseconds per iteration
- 20 iterations without the line: 2380.95 microseconds per iteration
- 20 iterations with the line: 844.85 microseconds per iteration
This indicates the overhead of the creation of the first label is
quite considerable even when using the default font. The default font
still has to be loaded when you create the first label. What you are
measuring here is.
1) load the default font inside the time loop (without the line)
2) load the default font outside of the time loop (with the line)
The difference in averages between the two will decrease as the number
of loops increases because you are averaging the overhead of the first
call over more consecutive calls.
example (timings are an example to illustrate the point):
load font: 30 ms
create label 1 ms
in loop time is:
((30+ 1) + 1 + 1)/3 = 11
outside of loop (font is already loaded when entering the loop and
widget using that font (.foo) still exists so there is no unloading
and loading of it in every loop.
(1+1+1)/3 = 11
now for 10^6 loops
in loop
(30 + 10^6) /10^6 ~ 1.000003
10^6/10^6 = 1
so the difference is much smaller which is what I meant by "know what
you measure"
Does this explain what I was trying to say better?
Mark
ZB
> The reason the label .foo is making a difference is because the
> label .foo is keeping a reference to the default font even though it
> is not displayed. This means that when you create the other labels the
> default font is still there when they are created (no overhead) and
> will not be removed when the font changes (the .foo label still has a
> reference so no overhead)
> That clears up why the label .foo makes a difference.
>
> When the reference count of the default font (lets call that x) is 0
> it gets unloaded when it becomes 1 it gets loaded.
>
> without .foo
>
>
> label .l -font y
> - create label with default font (x->1 -> load font)
> - change font to y (x -> 0 -> unload)
> repeat
>
> with .foo
> label .foo (x->1 -> load font)
>
> label .l -font y
> - create label with default font (x->2 font already loaded)
> - change font to y (x -> 1 -> font remains loaded)
> repeat
> [..]
> Does this explain what I was trying to say better?
Yes, thanks - it sounds very likely, but there's one thing left: there is
above: "change font to y (x -> 0 -> unload)". But to make such change -
shouldn't be font y loaded first, in similar way, as font x has been loaded?
If I properly understood, in the loop:
set report [time {
label .label$ii -text "label #$ii" -font "Helvetica 10"
pack .label$ii
puts $ii
incr ii
} 200]
...there are "complete" (from beginning to end) operations, among others the
default font is still loaded and then unloaded again, and again (without that
".foo" label line before loop, of course).
So, when there is "label .foo" commented out - and there's no reference to
default font (it's _not_ already loaded) - there must be 2 fonts loaded,
(almost) exactly, as you wrote:
1. create label with default font (x->1 -> load font)
2. change font to y (x -> 0 -> unload)
"Almost" - because there should be a point "1a": (y -> load font) - am I right?
Because "Helvetica" isn't present in any Tk's font cache?
Default font is:
tclsh8.4 [~]font actual default
-family fixed -size 12 -weight normal -slant roman -underline 0 -overstrike 0
...so, as we can see, it isn't Helvetica. So, there's a need to load default
font first, and then _before_ we change it, to load that different font (or
the characters from same font, but of different size).
And because of this my doubt: is it really so, that loading the first font -
the default one - always takes about 25 times longer, than loading the second
font? Why?
Pay attention, that difference "with or withour .foo line" isn't 2 times
longer. It's 25 times longer, when the default font has to be loaded again
and again (according to your explanation).
Or am I still missing something?
It all sounds, that "label .foo" line spares default font loading (and then
unloading) procedure. But what about the second font (that demanded one)? Is
it loaded really so much, much faster - that we can omit the influence?
Even, when second font has to be loaded at every iteration again ("label .foo"
presence "gives" us only the default font immediately "at request")?
--
ZB
ZB
> The reason the label .foo is making a difference is because the
> label .foo is keeping a reference to the default font even though it
> is not displayed. This means that when you create the other labels the
> default font is still there when they are created (no overhead) and
> will not be removed when the font changes (the .foo label still has a
> reference so no overhead)
> That clears up why the label .foo makes a difference.
One thing, I forgot to ask:
One will notice the "acceleration effect" even in case, if there'll be two
lines:
label .foo
pack forget .foo
...and then the main loop.
I'm not sure: doesn't "pack forget .foo" destroy the reference to the
default font together with the widget?
--
ZB
Mark Janssen
> Dnia 27.08.2007 Mark Janssen <mpc.jans...@gmail.com> napisa³/a:
>
>
>
Correct, but this only happens once because you are keeping a
reference to the y font (the labels you already created)
>
> If I properly understood, in the loop:
>
> set report [time {
> label .label$ii -text "label #$ii" -font "Helvetica 10"
> pack .label$ii
> puts $ii
> incr ii
>
> } 200]
>
> ...there are "complete" (from beginning to end) operations, among others the
> default font is still loaded and then unloaded again, and again (without that
> ".foo" label line before loop, of course).
>
> So, when there is "label .foo" commented out - and there's no reference to
> default font (it's _not_ already loaded) - there must be 2 fonts loaded,
> (almost) exactly, as you wrote:
>
> 1. create label with default font (x->1 -> load font)
> 2. change font to y (x -> 0 -> unload)
>
> "Almost" - because there should be a point "1a": (y -> load font) - am I right?
Yes, but as I mentioned above that will only happen once because on
the next loop you still have the previously created labels that keeps
the font loaded. The 'y' font never unloads.
> Because "Helvetica" isn't present in any Tk's font cache?
>
When starting nothing is present in the font cache.
> Default font is:
>
> tclsh8.4 [~]font actual default
> -family fixed -size 12 -weight normal -slant roman -underline 0 -overstrike 0
>
> ...so, as we can see, it isn't Helvetica. So, there's a need to load default
> font first, and then _before_ we change it, to load that different font (or
> the characters from same font, but of different size).
>
> And because of this my doubt: is it really so, that loading the first font -
> the default one - always takes about 25 times longer, than loading the second
> font? Why?
>
No loading of a different font takes the same amount of time:
(mjanssen) 1 % time {label .l} ; # loading default font
570 microseconds per iteration
(mjanssen) 2 % time {label .l2 -font "Helvetica 10"} ; # loading other
font
601 microseconds per iteration
(mjanssen) 3 %
> Pay attention, that difference "with or withour .foo line" isn't 2 times
> longer. It's 25 times longer, when the default font has to be loaded again
> and again (according to your explanation).
The main difference is that the default font keeps getting loaded and
unloaded on every iteration, whereas the Helvetica font is not because
it is still being used by labels created in previous loops (as I
explained above)
>
> Or am I still missing something?
>
> It all sounds, that "label .foo" line spares default font loading (and then
> unloading) procedure. But what about the second font (that demanded one)? Is
> it loaded really so much, much faster - that we can omit the influence?
> Even, when second font has to be loaded at every iteration again ("label .foo"
> presence "gives" us only the default font immediately "at request")?
> --
The second font doesn't have to be loaded again and again as I
mentioned above. I think you will see the same timing behaviour for:
1) -font y with the .foo line
2) without -font y and without the foo line.
Mark
> ZB
Mark Janssen
> Dnia 27.08.2007 Mark Janssen <mpc.jans...@gmail.com> napisa³/a:
>
No it unpacks the widget (which wasn't packed anyway). But the widget
still exists. (You can still pack it). To destroy the reference use
[destroy]. It might make sense to revisit the example by Joe English
now as that might make more sense in light of the recent discussion.
Mark
ZB
>> Yes, thanks - it sounds very likely, but there's one thing left: there is
>> above: "change font to y (x -> 0 -> unload)". But to make such change -
>> shouldn't be font y loaded first, in similar way, as font x has been loaded?
>
> Correct, but this only happens once because you are keeping a
> reference to the y font (the labels you already created)
> [..]
> Yes, but as I mentioned above that will only happen once because on
> the next loop you still have the previously created labels that keeps
> the font loaded. The 'y' font never unloads.
Ah, that's I was missing. It's not just "displayed and thrown away after
use" - it's still kept somewhere. Thanks.
So, as conclusion: it seems, that in case, when the window containing many
little widgets is being build - it's worth to have such "fake", invisible
widget; just as kind of default font "cache".
--
ZB
Mark Janssen
> Dnia 27.08.2007 Mark Janssen <mpc.jans...@gmail.com> napisa³/a:
>
Indeed, another possibility is to set the default font to the one you
are actually using in the beginning of the script.
something like:
option add *Label.font "Helvetica 10" widgetDefault
This way you will not have to use the -font anymore and performance
should still be good.
Mark
ZB
> option add *Label.font "Helvetica 10" widgetDefault
>
> This way you will not have to use the -font anymore and performance
> should still be good.
That "Tk font logistics" must be quite differently solved in the case of
Windows; it's hardly to believe, that both you and Bryan Oakley have so
powerful machines, that [time] didn't display any single microsecond just
because of the processor power.
--
ZB
Mark Janssen
> Dnia 27.08.2007 Mark Janssen <mpc.jans...@gmail.com> napisa³/a:
>
>
> > This way you will not have to use the -font anymore and performance
> > should still be good.
>
> That "Tk font logistics" must be quite differently solved in the case of
> Windows; it's hardly to believe, that both you and Bryan Oakley have so
> powerful machines, that [time] didn't display any single microsecond just
> because of the processor power.
> --
> ZB
Actually when timing I did see a difference, but not a noticable one.
(I can't see a 0.4 ms difference) With regard to Bryan's machine that
must be blazingly fast (one loop for me took ~ 200 microseconds)
Mark
ZB
> Indeed, another possibility is to set the default font to the one you
> are actually using in the beginning of the script.
But it seems to me as kind of error in the logic, that default font has
always to be loaded - despite of this, that widget wants different one.
Perhaps the people, who are working on 8.5 should be notified about this?
--
ZB
Mark Janssen
And of course you are probably right that font loading on Win32 is
much faster.
Mark Janssen
I suspect loading a font (or any other resource) is generally faster
on windows than on X11, because of the different designs (X11 is
client/server, Win32 are local API calls)
ZB
> I suspect loading a font (or any other resource) is generally faster
> on windows than on X11, because of the different designs (X11 is
> client/server, Win32 are local API calls)
^^^^^^^^^^^^
Yes, you're right: exactly that has to be the key.
--
ZB
Mark Janssen
> Dnia 27.08.2007 Mark Janssen <mpc.jans...@gmail.com> napisa³/a:
>
> > are actually using in the beginning of the script.
>
> But it seems to me as kind of error in the logic, that default font has
> always to be loaded - despite of this, that widget wants different one.
>
> Perhaps the people, who are working on 8.5 should be notified about this?
> --
> ZB
Note that if you specify a different default font, the font you are
actually using, is the only one being loaded. So this seems like a
perfectly valid way to achieve the desired behaviour.
Although one could argue that Tk is a bit too aggressive when
unloading fonts.
In any case, Tk maintainers are aware of this and it might not be easy
to fix.
Please log a bug at http://sourceforge.net/tracker/?group_id=12997&atid=112997
Mark
ZB
> Note that if you specify a different default font, the font you are
> actually using, is the only one being loaded. So this seems like a
> perfectly valid way to achieve the desired behaviour.
Yes, I agree with the above...
> Although one could argue that Tk is a bit too aggressive when
> unloading fonts.
...but I meant about policy. Presently - after our yesterday's talk - it
looks to me, that it works in the following way:
1. A widget has been created (not packed yest).
2. Immediately then a default font is loaded "just in case".
3. Only then there's a check: "Hey, but the widget wanted a different font!"
4. Unloading of a (unnecessary loaded) default font.
5. Loading the demanded one.
So, my very simple idea is just to swap the points 2 and 3 - to check first,
if there has been "-font xyz" option added. In such way we could spare two
unnecessary steps.
Yes, setting different font as default is kind of cure as well - but one has
to know first, why it's _much_ better than using the options. I didn't know
it earlier - and because of this my yesterday's confusion about so big time
difference, when building window. And about the meaning of unnecessary line.
I'm afraid, without Joe's explanation we could be still wondering. ;] It's
not described on manual pages.
--
ZB
Mark Janssen
> Dnia 28.08.2007 Mark Janssen <mpc.jans...@gmail.com> napisa³/a:
That would be a solution indeed, but this is unfortunately not easy to
implement in Tk at the moment. Widget creation has to come before
setting of the widget options (as far as I understand it). Please do
log a bug to request attention to this issue (if only for reminder
purposes)
This is not something that should be in the man-page IMO, it's low
level details and the script writer shouldn't have to worry about
that. Documenting it will mean people will start depending on this
behaviour in their scripts and then it cannot be fixed without
possibly breaking those scripts.
Mark
Joe English
>
>What are the results if outside of the loop he uses the font command to
>create a named font and that named font in the label commands?
Unfortunately, creating a named font doesn't help.
Named fonts don't hold a reference to the cache,
they're just symbolic aliases (sort of). So even
if you create a named font, Tk will still only
instantiate the font when it's first used, and
deinstantiate it when the last reference goes away.
--Joe English