Jan 13, 2012 at 7:30am



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!

Jan 13, 2012 at 7:03pm


yep, but you should keep a pointer to your font in the object structure … not sure it is good for CPU cache stuff (in case of lots of them) …

My 2 cents.

Anybody ?

Jan 14, 2012 at 6:47am


to explain my post a little bit i have to said that i observed that the object structure size (of my Tralala UI) is more than 2Mb (more than half is t_jrgba stuff and so) ; i’m used to instantiate everything first, but maybe it’s not always a good idea … specially as paint () method is executed anyway in the “main” thread.

but that is just an opinion ; and for sure it should be great to know if there is any technical reasons to not do that ;-)

Jan 14, 2012 at 8:43pm

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…


Jan 16, 2012 at 6:19am


you are right, in your case cpu cache stuff is not really pertinent ; the things to know is if t_jfont (i don’t have any idea of what is really this stucture inside) is thread safe.

Jan 16, 2012 at 10:00am

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…

Jan 19, 2012 at 2:14pm

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.


Jan 20, 2012 at 10:25am

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



You must be logged in to reply to this topic.