You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Performance of string handling methods, such as ImGui.text or ImGui.calcTextSize etc could be improved by avoiding copying using JNI GetStringCritical instead of GetStringUTFChars. This copying can be quite an overhead on text-heavy user interfaces.
The text was updated successfully, but these errors were encountered:
GetStringUTFChars converts Java UTF-16 text to native UTF-8. Although GetStringCritical gives us jchar*. Even that ImGui supports UTF-16: in a form ImWchar type, yet it's not quite what we need for everything, like ImGui#text which requires char*.
We could pass raw bytes[] from Java, yet it still needs conversions to be done. Do you have thoughts about that?
Hm... A further complication is Java 9 compact strings, which encodes LATIN1 strings on 8 bits, the rest as UTF16 – neither of which is UTF8 :) I guess ASCII strings could be used directly – it's probably still more efficient to detect if the string is ASCII only (no high bits) than it is to allocate/copy/release a new buffer.
Maybe another way to reduce the overhead is to do the copying conversion into a pre-allocated buffer, eg. using GetStringCritical + ImTextStrToUtf8, instead of Get/ReleaseStringUTFChars (which allocates a new one, AFAIK)
Performance of string handling methods, such as
ImGui.text
orImGui.calcTextSize
etc could be improved by avoiding copying using JNIGetStringCritical
instead ofGetStringUTFChars
. This copying can be quite an overhead on text-heavy user interfaces.The text was updated successfully, but these errors were encountered: