Touch input jitter on Android

I seem to be getting some kind of touch input lag / jitter using SDL with
Android. It feels noticeably stuttery compared to just using the Android
SDK. To create a minimal demo of the difference, I created two
applications: one with SDL and one using the Android SDK.

Both these applications simply draw a square at the position touch input is
received. On my device, the application written with the Android SDK feels
much smoother.

Source for Android SDK version:

APK for Android SDK version:
https://mega.nz/#!7NJgSLAS!cgdaRDVZz4pjIAtWdAwda-xMlTbkFT82o1hsl3_pcDM

Source for SDL version:

APK for SDL version:
https://mega.nz/#!aJRxSayK!Fjht0jFNjZWvf__aAg2cJg4iMVgXQxqrlhxDv2ZLM5A

There is no input lag for SDL on the desktop. There is no lag or stutter
when something unrelated to input position is animated so I don’t think its
a rendering issue, I think its just related to input position.

Does anyone know why this might be happening? Am I handling the inputs in
SDL incorrectly? I’d appreciate any advice.

Hi Preet, welcome.

SDL touch events are in the range of 0 to 1.

https://wiki.libsdl.org/SDL_TouchFingerEvent

And you will want to look at SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH

Hope this helps.

Hi Preet, welcome.

SDL touch events are in the range of 0 to 1.

https://wiki.libsdl.org/SDL_TouchFingerEvent

And you will want to look at SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH

Both of these are unrelated to the issue here.

The problem is sort of obvious and I feel silly for wasting so much time on
it. Input events can queue up. In my SDL example I only rendered the latest
touch data, including batches of events that may have been sent between
iterations of the event processing loop. If you instead render each input
event position in a separate frame, the jitter is gone. It makes sense that
the position would jump around if you ignore in-between events.

while(keep_running)
{
    // drain all available events
    while(SDL_PollEvent(&event) != 0) {
        if(event.type == SDL_QUIT) {
            keep_running=false;
            break;
        }
        else if(event.type == SDL_WINDOWEVENT) {
            if(event.window.event == SDL_WINDOWEVENT_RESIZED) {
                g_win_width = event.window.data1;
                g_win_height = event.window.data2;
            }
        }
        else if(event.type == SDL_MOUSEMOTION)
        {
            input_x = event.motion.x;
            input_y = event.motion.y;
            break; // <--- BREAK HERE SO EACH TOUCH POSITION UPDATE IS

RENDERED SEPARATELY
}
}

    render(prog_id,vbo_id,attrib_loc_position);
}On Wed, Apr 20, 2016 at 3:29 PM, AntTheAlchemist <ant at powgames.co.uk> wrote:

After messing with the result of rendering each touch position separately
the output seems smooth but still slower some how than with the Android SDK

As best I can tell you aren’t throttling how many frames per second you
render in the SDL version. The Java SDK version probably manages that for
you with its canvas widget. I suspect that’s the main problem. To verify,
count how many motion events you get per second and how many frames you
render per second in each test. Then disable rendering entirely and see how
many motion events you get. You might also calc min/max/avg frame times to
see if you get any spikes – they can significantly impact your sense of
fluid responsiveness.

Also, you recreate the VBO every frame. That is a relatively expensive
function – can you find a way to reuse the VBO? Chances are this is not
the problem but if you’re going to do anything complex or latency sensitive
you might consider addressing it.

Cheers,

MattOn Apr 20, 2016 15:07, "Preet" <prismatic.project at gmail.com> wrote:

After messing with the result of rendering each touch position separately
the output seems smooth but still slower some how than with the Android SDK


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

As best I can tell you aren’t throttling how many frames per second you
render in the SDL version. The Java SDK version probably manages that for
you with its canvas widget. I suspect that’s the main problem.

I have vsync on, so that should be throttling frame rate to 60fps. Turning
vsync on and off doesn’t make a difference (maybe Android forces vsync?) so
I’m not sure this is the issue.

To verify, count how many motion events you get per second and how many
frames you render per second in each test. Then disable rendering entirely
and see how many motion events you get.

Frame time is 16ms. I get 0,1 or 2 motion events per frame with 1 per frame
being the most common.

Also, you recreate the VBO every frame. That is a relatively expensive
function – can you find a way to reuse the VBO? Chances are this is not
the problem but if you’re going to do anything complex or latency sensitive
you might consider addressing it.

I’m just recreating the VBO for the simple test app, I wouldn’t be doing
this for a proper project. Given that by rendering each touch input one at
a time the jitter goes away I don’t think this is a bottleneck or affecting
the output.On Wed, Apr 20, 2016 at 8:23 PM, Matthew Helsley <matt.helsley at gmail.com> wrote: