turbobadger
turbobadger copied to clipboard
fruxo
TBEditField rendering performance
Did some profiling a couple weeks ago, and noticed that every word in a TBEditField is rendered individually, even if there's no different style applied to any of them, causing it to be quite slow.
(Sorry for the jpeg-artifacts, grabbed the screenshot from a compressed chat window :))
This was profiled on the shape rasterizer branch (actually the NimbleTools fork, but it's pretty much the same).
Are you aware of this? Are there any plans to improve this performance? If not, I'll probably look at it myself at some point. Why are the words drawn individually? Wouldn't it be faster to render each line individually for example?
What is taking time in TBTextFragment::Paint then? Are you using many fonts? I guess the GetFont call in it could be slow.
I haven't had any performance problems with it. For normal text, there shouldn't be many text fragments. But with things like many word-breaking characters, it could be pretty bad, resulting in one fragment per character. Imagine f.ex a line like "====================================="
Avoiding fragments unless styling or wrapping requires it would be an interesting optimization.
27ms spent in TBEditField::OnPaint seems insanely slow but i guess profiling itself made it a lot slower?
No, that's the entire reason I started profiling it. The profiler I'm using has an overhead of about ~50us if I remember correctly (per begin/end call for the zones).
The text in question was a relatively simple piece of text with average word lengths, nothing super long like that. There's some word wrapping involved though.
The font used is a Truetype font, too. Perhaps that has something to do with it, but considering it caches all the characters on a bitmap I don't think that could be the issue.
I did some profiling on master and made some optimizations (will try to push something within a few days..). However, on the shape rasterizer branch, the new kerning support is adding 30% cost for drawing text compared to the nonkerned version on master (all in GetAdvance). That's with STBFontRenderer. I haven't tried freetype. Maybe glyph advances should be cached.
TBEditField doesn't measure during painting though, so that doesn't really explain this issue.
Thank you! I had a suspicion that the rasterizer branch would have some changes that caused it to be a bit slower. I'll have to try and revert our codebase back to master branch and see if that solves the issue.
It's actually an in-house profiler that we made at @Crackshell that we've wanted to release as an open source project, but never got around to it yet.