The documentation on Wiki doesn’t mention this, but Text Input is active by default.
I noticed this, because I was seeing jitter in my frame rate. And this jitter was induced by pressing a key on the keyboard! Even though there was no game functionality behind the key.
Every time I press a key (or autorepeat a key) my game has a slow frame followed by a fast frame.
This is because an enormous amount of work is performed (34 deep function calls) to process a key when in Text Input mode, even if there is no text visible on screen.
I wrote up my findings here:
I have three possible solutions (sorted from easy fix to harder fix):
(1) Fix manual to mention that it is on by default.
(2) Don’t turn on Text Input by default.
(3) Make Text Input mode more efficient.
Calling SDL_StartTextInput() has the side-effect of displaying the on-screen-keyboard on mobile platforms (Android or iOS). I don’t want that to happen, but I do want keyboard input to be active on desktop platforms. That is exactly the situation that arises when you don’t call SDL_StartTextInput(), so I don’t!
I agree that changing textinput to not be enabled anymore on desktop platforms is not a good idea and would probably break code.
To be honest, I have no idea how this IME input stuff for Asian (and probably other) languages that’s mentioned in the tutorial works - neither from a users nor from a developers point of view.
Maybe part of the problem here is that this IME and screen keyboard stuff is somehow mixed up with text input from “just typing on the keyboard”, as both apparently generate SDL_TEXTINPUT events and require SDL_IsTextInputActive() - even though “normal” (non-IME) text input should be possible with a lot less overhead (a difference is that the normal/simple input doesn’t seem to generate SDL_TEXTEDITING events).
Does anyone know how this really works with IME and has actually used it themselves?
Could there be a way to decide whether to do generate SDL_TEXTINPUT events the easy/cheap way (like it’s done when SDL is built without support for IBus)?
Maybe if SDL_SetTextInputRect() hasn’t been set?
True, but if you want to receive ‘ordinary’ character-based (i.e. alphanumeric) input from the user then SDL_TEXTINPUT events must be enabled, and in my opinion it is sensible that they are enabled by default. I would tolerate IME, Text Composition and/or On Screen Keyboard being initially disabled, but not text input events.
I’m uneasy with the idea that “just typing on the keyboard” doesn’t require an IME, because of the implied ‘Western’ bias. For a significant proportion of the world it’s not possible to “just type” without some method of text composition. Since SDL2 uses Unicode throughout it should probably be IME-compatible throughout too.
I would expect the IME candidate list still to be displayed (in a default place) even if SDL_SetTextInputRect() hasn’t been called, so I don’t think that would be a compatible change. Personally I wouldn’t mind if SDL_TEXTINPUT events were generated an “easy/cheap way” unless and until SDL_StartTextInput() was called, but that might not suit some existing programs.
I just think like you have to enable joystick input you should ask to enable keyboard support per se. If you don’t need the keyboard why activating it?
And I think there are cases where the arrow key is just the arrow key.
Those input methods aren’t the solution for everything. If the right control key is missing, e.g. on plenty notebooks, it’s missing.
Input methods aren’t a chimaera either.
But don’t get me wrong, I don’t have a strong opinion about that.
I had a look into several input methods in the past and I think it’s a mess, like usually. It’s just about looking into SDL implementation. Still haven’t looked into it.
I thought about that, but I think supporting non-Western text needs a lot more additional work than just calling SDL_EnableIME() or something like that - probably even more work if SDL_TEXTEDIT events need to be handled.
I’m not exactly sure how SDL_TEXTEDIT works, but if I understand https://wiki.libsdl.org/SDL_HINT_IME_INTERNAL_EDITING correctly, with that hint set to 0 you get SDL_TEXTEDIT events and need to display the composition stuff yourself, if you set it to 1 (and if available) a system IME window is used (probably at SDL_SetTextInputRect()?).
BTW, I wonder what it’s like with non-Latin alphabets like Cyrillic or Greek or Thai or Lao - do they need IME or is it like “normal” text input, but yielding the appropriate unicode chars?
Also, with dead keys there exists simple char composition even in western languages, but no IME is shown for that and it still works with SDL.
In theory I wouldn’t mind too much if SDL_StartTextInput() needs to be called for it to work.
But in practice, as has been pointed out before, changing the behavior of it being enabled implicitly on Desktop platforms would break existing code, so it can’t be done before SDL 2.1 - so we need a solution that reduces the overhead without causing too much damage in existing applications.
Remember: Most Linux games on Steam use SDL2 - we wouldn’t want them to break, right?
Especially considering that games tend to not be too actively maintained once they’re “done”.
(But we also don’t want existing Linux games to stutter whenever buttons are pressed, so leaving it as it is isn’t an option either)
Very strange, optimizing text input is the correct choice, why is it so slow on Linux, but not an issue on any other platforms?
Also rather than changing the standard behavior and breaking everyones programs, the better solution is for those who want it off to simply turn it off on startup like you have done. Perhaps on a major release where people expect things to change to turn it off by default?
Have others reported or noticed this? Have you tested on other machines? Perhaps it has something to do with a specific driver or hardware you have?