Three words - variable width fonts. And even if I approximated to fixed width, I still need to know how wide the text renderer will render them since both font and size are configurable. I'd also still need to know the image width. I get the impression that omxplayer renders video at native resolution unless the -r option is given to make it fill the screen, and even then it sounds like it is just resetting the output display size, so either way I'd need to know the image width.
And clearly the text renderer on "center" align is taking the width of the string into account to display it centred - it must do. So since we are calculating the render width of each sub-string when working out the word wrapping, it makes sense to remember that value and pass it back to save having to repeat the calculation. The Raspberry Pi is hardly over-endowed when it comes to processing power.
i'm sorry if I am sounding picky, but one reason I just got given the worst written piece of crap at work is because the people who gave it know that I am extremely picky when it comes to the quality of the software I write and am a bit of a perfectionist, and they are fed up with the quantity of bugs in this thing. That's who I am - I don't believe in doing a half-arsed job of work.
I'm currently struggling to build my own cygwin based cross-compiler because my Windows 7 install refuses to act case sensitive when dealing with the file system despite me setting all the relevant registry entries. Once I have a cross-compiler I'll do a compare of omxplayer and VLC with hardware support enabled and if omxplayer wins (from what I have read it will) then I'll implement a proper fix and offer it up as a pull request.
From what you say, you want UTF8 strings encoded as vectors of UTF 8 code points, by which I guess you mean characters. They are not ints. UTF8 is variable width. Why do it as a vector of characters? It's extremely memory inefficient to encode the whole string in that way when a simple null terminated byte array is sufficient. Putting each sub-string in a vector is fair enough, if you must suffer the memory overhead of using C++ vectors in the first place
but putting each character as an individual element in a vector... What's the overhead of each element of a vector? I'd be surprised if it was less than 4 bytes, so the overhead will be more than 100% of the actual data size!