jfont_create()

andrea agostini's icon

Hi.

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!
aa

andrea agostini's icon

Hi vanille

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...

aa

andrea agostini's icon

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...

Timothy Place's icon

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.

Cheers,
Tim

andrea agostini's icon

Thank you - no, I don't have evidence of jfont_create calls being particularly expensive, I was just speculating

Cheers
aa