Font Baker reuse

[molecularentropy]

I have complete success using the font baker in a clean-startup/complete-shutdown sort of fashion. However, I'm trying to optimise a little. The docs say that cleanup() is if you don't want to use the baker, and clear() is if you don't want to use the atlas as a whole anymore. To me, this dictates the following flow.

• init()
• • begin()
• • • add_*()
• • • add_*()
• • • bake()
• • end()
• clear()

Now, let's say I only add fonts once, but the window gets shut down, so I need to upload the texture again. As long as I'm still in between the init() and clear(), it should be safe to do:

• • begin()
• • • bake()
• • end()

But I get a glibc corrupt linked list error and SIGABRT when I do this. Apparently the image supplied by the baker on the second call of bake is bad somehow.

So, am I wrong to assume I can just rebake already-loaded fonts?

[dumblob]

I think you'll need to dive into the Nuklear source code for the correct answer. In case you'll find anything suspicious, feel free to make a pull request.

[molecularentropy]

Is this project no longer being developed? I'm happy to dive in, but as always, the original author can probably tell me what's up in seconds.

[dumblob]

Is this project no longer being developed?

It's in a healthy maintenance mode (including some development, but not anything extreme - we're trying to be backwards compatible). Just look at commits, pull requests, etc. to get an idea.

I'm happy to dive in, but as always, the original author can probably tell me what's up in seconds.

Well, it's not that straightforward - immediate mode UIs appear to be extremely fragile when it comes to development and hundreds of subtle decisions have severe impact on the whole library (this is what the main author of Zahnrad, which is the former name for Nuklear, said about it and I fully agree). So actually I would say noone could tell you "what's up in seconds" in case of Nuklear without looking at the source code thoroughly in advance. The code is though well structured, so if this issue is not yet another subtlety having impact on the whole library, you should find the culprit in minutes rather than hours :wink:.

[prust]

@molecularentropy: I think @dumblob has been the de-facto lead maintainer for a while now, has worked closely with vurtun and probably knows the library as well as anyone. TBH, I don't understand why he donates so much of his time to the project (but I am thankful he does).

[molecularentropy]

Okay, I've made a pull request. Works for me. Please review.

[dumblob]

Solved, thanks again.