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
