From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Mon Jul 29 2002 - 04:36:59 EDT
I have done a bit of profiling yesterday, and
gr_Graphics::remapGlyph() came up as the most time-consuming
function in the application. The hack I just committed moves it way
down the list.
The hack works on the two assumptions:
(1) the preference scheme cannot change in the life-time of the
application, simply because we have no UI that would allow that;
when/if if implement such an UI, we need to add a listener to the
class to handle the change, not to examine whether the scheme
changed or not inside remapGlyph().
(2) The remaping switches cannot change at runtime also because
we have no UI for that. Further, the changes to the the remaping
switches do not require the tables to be automatically deleted, only if
the new tables are bigger than the old ones. Again, when/if an UI is
added, we need to add a listener to the class, not run the tests within
remapGlyph().
So I have moved all the code that deals with preferences into the
constructor.
Tomas
This archive was generated by hypermail 2.1.4 : Mon Jul 29 2002 - 04:46:06 EDT