Font rendering with ofxDatGui in a multi-window application

I love ofxDatGui, and am now trying to get it running in a multi-window application as described in this oF 9.0 blog post (link).

So far I’ve discovered that you have to disable autodraw and call draw manually in each of your application loops to make sure the GUI is drawn to the correct window-- but I’m still having trouble rendering fonts. It looks like it has something to do with the included ofxSmartFont addon not being able to be “seen” from one application class once a gui has already been instantiated in another one-- the result is a bunch of boxes instead of characters, as seen below.

Does anyone know of a way to get ofxSmartFont to work across both applications?

1 Like

I’m just running into this now, trying to use multiple ofxDatGui objects in one Android app.

What I’m seeing is that it works on Windows, and often works on Android, but seemingly randomly, it fails to load the font right and it displays as you showed, in all of my controls.

Did you figure out a fix?

I am thinking I may need to hack ofxDatGui some more to get it to work, but I don’t really see what the problem is that is causing it.

Upon further testing, it seems that ofxSmartFont is failing to correctly determine when it needs to load the font or not.

Because if I make it re-load a new size of the font that’s messing up, then it loads that fine, but if I return to the messed-up size, it shows the blocks.

I am inferring that it checks and thinks it has a font loaded, but actually Android has tossed that font out?

Is there a way to tell ofxSmartFont to be sure it really has usable font data, and if not, to make it reload it?

Ok, so I have a work-around, which could be improved into a fix if anyone knows (or I take the time to devise) a way to programmatically test whether a font really has a font correctly loaded in it.

The workaround is to hack ofxSmartFont::add() to not “smartly” look for an existing font of the same type and size, but instead to always make a new one.

The real fix would be to add a valid test for whether not only is there a font object that’s supposed to match the one wanted, but whether it’s actually got a good font in it or not.

i.e. the place to fix it would be in the first “if”, to add a test that actually validates that the font has a well-loaded font in it. I don’t see such a method already exists. Does anyone know of a good way to test for that?

in ofxDatGui’s ofxSmartFont.cpp:

std::shared_ptr<ofxSmartFont> ofxSmartFont::add(std::string file, int size, std::string name)
    for(auto f:mFonts){
        if (f->file()==file && f->size()==size){
           // log(f->name() + "@ pt size "+std::to_string(f->size()) + " is already in memory.");
            return f;
    struct make_shared_sf : public ofxSmartFont {
        make_shared_sf(std::string file, int size, std::string name) : ofxSmartFont(file, size, name){}
    mFonts.push_back(std::make_shared<make_shared_sf>(file, size, name));
    return mFonts.back();