Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improve string handling performance #224

Open
phraktle opened this issue Mar 3, 2024 · 3 comments
Open

improve string handling performance #224

phraktle opened this issue Mar 3, 2024 · 3 comments
Labels
feat New feature or request

Comments

@phraktle
Copy link

phraktle commented Mar 3, 2024

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.

@SpaiR SpaiR added feat New feature or request api labels Mar 3, 2024
@SpaiR
Copy link
Owner

SpaiR commented Mar 4, 2024

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?

@phraktle
Copy link
Author

phraktle commented Mar 4, 2024

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.

@phraktle
Copy link
Author

phraktle commented Mar 4, 2024

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)

@SpaiR SpaiR removed the api label Sep 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants