Looking at the XParseColor, there are possibilities
for speedup which cost nothing (except time to
implement it)
- The binary search algorithm keeps track of 3 state
variables (l, u and i), which can be reduced to 2
(step and p).
- The color table contains entries for both entries
like "aliceBlue" and "alice blue". When we write
a custom strcasecmp, in which a capital in the
table matches a space+character in the color
spec, those two table entries can be combined
to one.
- inline FindColor, it's just a small function.
The measured speedup is about 5%. The color
table size is reduced from 752 to 657 entries
Further speedup ideas:
- If we put indexes of the table to the letters 'a'-'z' in a small table, we
can split the color table into 26 (actually 20) separate tables. That
saves about 4 string compares for each XParseColor!
- We can combine the colors of 5 related entries (e.g.
azure, azure1 - azure4 into a single table entry.
This brings back the number of table entries from 657
to 147 ! That's both a speedup and less memory
usage.
committed now to branch rfe-3503317
color table is complete, only the handling of
the additinal colors is not complete yet.
All speedup ideas now implemented. Added test cases for
all available colors, and a file rgb.txt, which contains a list
of all colors accepted by Tk for all platforms.
So, I consider this tested will enough to be 100%
thrusted. Test case color-1.5 proves that.
Committed to core-8-4-branch, core-8-5-branch
and trunk.