I made a similar post about this in the past and am revisiting the project after a hiatus.
I have a really simple android application demo using SDLActivity. I’m rendering a square using OpenGL onto the application window. The position of the square is updated each frame based on the user’s touch input. I see some occasional jitter that looks like dropped frames or lag. I think the source of this issue is that some frames don’t have any touch data events or that some frames have multiple touch inputs data events. I render the position data received from the last touch event each frame. The application is using vsync and I am looping in a busy-loop, rendering at the end of each iteration after draining all events.
Has anyone else noticed this in their own projects or is it just me?
If anyone’s willing to try out the APK on their device, do you see the same issue? I am testing on a Nexus 4. If you don’t trust the APK, the sources are all there in the AS project dir and the gist. I do not have another Android device to test this with.
If this isn’t a device-specific problem, does anyone know how to fix the jitter? I’ve tried to recreate a similar application (draw a square pinned to touch input position) using just the Android SDK framework stuff and I don’t see any lag / stuttering.
I tried the APK on my Redmi Note 3 Pro (Android 6.0.1). I didn’t notice any micro-stutter but there was a lot of lag, the red box doesn’t keep up with my finger very well. Also the red square wasn’t traveling across the entire screen, just the bottom-left third of my screen, which made it harder to gauge how well that box was tracking my finger.
Sorry if this isn’t very helpful but I thought it’d be better than nothing!
I tried downloading the APK but I didn’t want to install their app or plugin.
But my educated guess of what you are experiencing (because I’ve
fought with this before in other contexts (i.e. not SDL)), is that the
fact that SDL’s Android implementation runs on a background thread is
the source of your problem, and why you don’t have the problem with
your native comparison program.
Because SDL is not running on the main UI thread, as your real Android
input events happen, they are being queued up to be handled by the SDL
event later when the OS switches back to the SDL thread. This
unfortunately interferes with perfect responsiveness.
However, I expected behavior more like Eric Wasylishen’s description
of a lag, and not a micro stutter.
The reason the red box only worked on the bottom left third of your screen is because I stupidly hard coded the resolution for my phone screen. Thank you for testing!
MEGA shouldn’t require you to download their plugin, you should be able to download it directly but I appreciate you trying.
I can tolerate an overall delay of a few frames so long as there isn’t a stutter. Unfortunately the stutter is very noticeable and really ruins the feel. To describe the stutter better, what I see on my device is as if I had received no touch inputs for a frame or two (so the square does not move at all during that time) and then it will jump forward. Looks sort of like a frame skip I guess.
We have seen some problems with some Android devices dispatching excessive touch events, hurting performance. I am not sure if it is related, but the following minor change to SDLActivity seems to help:
Other than something like that, you may need to decouple your animation and touch input code, in order to smooth the result. I usually use the touch input as a target (x, y), but have a separate update that animates toward the result