I am on Unity 2018.4.14f1, and am on  latest STM (v1.9.2).

When toggling  the active state on some gameobjects using UI STMs that are set to the same font & not auto-read, I occasionally see something like this:

The second button is supposed to say "OPTIONS" here. I can repro it 100% of the time by opening this menu, closing it, opening a different menu with some similar STMs, closing that, and then opening the original menu again. The options text is always the one corrupted here, and in the other menu the text "-- Start --" is corrupted on opening that menu again a second time. Both menus are inactive on start. So, this seems related to OnEnable being called after the mesh has already been built once.

I have confirmed Rebuild() is being called on it when enabled. When I mouse over the button my code triggers a Rebuild that corrects the mesh.

Adding a call to WaitFrameThenRebuild in SuperTextMesh.OnEnable seems to fix the problem, but having to call Rebuild twice is not ideal for performance: https://pastebin.com/QimMki3u

If I call WaitFrameThenRebuild instead of Rebuild, rather than calling both as in my paste, only the first character on the options string is corrupted, and the rest are fine.

Any idea on this? Worst case I can keep my workaround in place, but I would love to be able to remove a second Rebuild call as it can be pretty costly.

Thanks!

Hey! I might end up implementing that workaround for now, so go ahead and use it. The next focus for STM is optimizing Rebuild() anyway. I think this bug is caused by OnFontTextureRebuilt() not firing, but I'm not 100% sure this time.

This is really good work narrowing down the bug though, I'm not at my computer right now, but I'll give it a proper look soon! If you can send me a sample project that repros the bug, that would help a lot!

Yeah, I think I want a repro project before I work further on this, sorry! I can't seem to repro it myself, even though you're able to repro it 100% of the time. It's gotta be the exact combo of text/font settings you have, maybe...? Causing a texture rebuild at an inopportune time...?

Either way, that bonus call shouldn't be an issue for most situations in-game... especially for STM objects with small amounts of text. The Rebuild() optimizations I'm working on will mainly affect longer strings of text in-editor.

Tried making a minimal scene with a repro but so far no luck. I can repro every time in the same way in one of my game's scenes but not in a smaller example, even when copying both UI's over. So I think you're right that it's some sort of timing issue. We are demoing at a con right now, so I'll keep trying when I have time but it may be a bit before I have it ready

Having something that *works* on time is more important for now, so lets go with your solution! I'd just want to test this myself before a *public* release so I can properly assess what's causing this... but a temp fix is fine when you have a demo to present! Best of luck at the con!