This merge request should be considered a draft. It creates a stop-gap solution for #12 (closed) by inverting the background / foreground color of keys upon clicking and tapping.
I would like to use this as a basis for a discussion about the approach taken. My C++ is less than poor and my experience with SDL ... well, what experience? So while this does seem to work in my own testing, I'm not really confident in what I'm doing here and parts of my changes are probably utter crap.
Implementation-wise, I changed the keyboard textures to have streaming access mode (which is supposedly optimized for frequent changes). When clicking or tapping a key, its area is recreated inside the surface (taking the selection state into account) and then copied into the texture.
Open questions on my end:
Is the general approach of updating the surface, then copying it into the texture advisable here? Reading into some of the SDL docs, it seems that textures are optimized for display so maybe we should rather perform all operations on the textures directly (if that's possible by any chance)?
Is it really necessary to convert the surface into the window's pixel format before every transfer into the texture? It seems like I could also directly create the surface in the window's pixel format from the start but I wasn't sure what side effects that might have.
I'm currently memcpying the whole pixel array into the texture on any touch / mouse down & up event. That's probably not very efficient. Is there an easy way to copy just the key rect?
Update
Answering part of my questions myself after having done more research.
It appears that texture's are stored in VRAM on the GPU whereas surfaces are stored in RAM which should in principle make textures a lot more performant than surfaces. The key drawing seems to be possible on the texture directly, e.g. there is SDL_RenderFillRect which could be used on the texture instead of SDL_FillRect on the surface. The only thing that appears to require surfaces as an intermediary step is the text rendering. To speed that up, we could cache the textures created for each character to be able to quickly draw them upon selection.
Drawing into the texture directly would eliminate having to constantly map all of the surface's pixels into the window format as well as having to manually copy pixels over from the surface into the texture.
Update 2
This fixes #12 (closed) and adds both key highlighting as well as character previews. I'm using the approach suggested by @MartijnBraam in the comments now. All highlighted keys are drawn into a separate texture. Upon rendering of the keyboard, both the normal and highlighted texture are combined to create the highlighting / preview effect.
I'd welcome feedback on the styling. Also, my C++ is still ugly so an opinionated review would be appreciated.
