In the SDK examples, fonts are always created at the beginning of the paint method and destroyed at the end.
Wouldn’t it be more efficient to create them once for all (say, in the setter of the corresponding attribute) and destroying at the same time the previous ones? Is there any reasons not to do so?
thank you for your hint. I wonder (maybe you have experience with that?) if cache misses and things like that make you waste more time than creating and destroying fonts at every call of the paint method. It is also true that the external we’re trying to optimize has a huge object structure with hundreds of fields, so probably keeping some more stuff won’t make a huge difference.
Actually I wonder if the point about creating and destroying jfonts in the paint method is about not having to bother for your font not being destroyed in the scheduler thread while it is in use…
Uhm… I guess it’s just some special kind of t_object. I don’t think it’s thread safe – after all, it is made for use in the main thread only…
It shouldn’t hurt anything to cache the font, but the cpu demands of the font lifecycle should be negligible, particularly when compared to painting. If you find that these calls are showing up in a time profile, please let us know.
Thank you – no, I don’t have evidence of jfont_create calls being particularly expensive, I was just speculating
C74 RSS Feed | © Copyright Cycling '74