I could see use cases for having a new class, something like CharArray, but it would probably end up being pretty much a wrapper around juce::Array<juce_wchar> with some helper functions. You could probably write your own such class without too much trouble!
writing such a class would probably be easy, yes. but it would be important that it’s supported by juce as well. cause a lot of times you make strings because you wanna use them in a juce::Graphics context so it would be important that the different drawText methods then also get some new overloads that accept the new type and utilize it smartly to enable the performance benefits they try to accomplish rather than converting everything to String regardless of its origin
I was thinking that the CharArray type would have a method to concatenate all the chars into one String, therefore the interface for all the places String is used wouldn’t have to change.
I think the main reason for having any kind of CharArray class would be to have some kind of special optimization going on when you do this concatenation – that’s what this whole thread has been about, anyway – but I’m not sure how possible that is.
1 Like
I think this whole optimization is completely misguided. drawText is a very slow function. Assigning a char* to a String is very fast. The difference is about 1000x or more. If you want performance you need to optimize the slower function. Probably have some pre rendered strings in bitmaps and then just blit the appropriate one. But honestly, trying to reduce one allocation in graphics code is a waste of time.
8 Likes
yeah i had the same idea yesterday. considering that i have a fixed set of characters i wanna use i could really just put them all into juce::Images and then just rearrange them. i have not benchmarked this idea yet tho, but you’re probably right