Multitouch slowdown

Hi.

I noticed a slowdown in the responsiveness of my application when I use a touchscreen and make contact with more than one finger. The idea is to equate a two fingers drag to a right click mouse drag to rotate the scene.

When I use the mouse, the scene moves and rotates smoothly and without delays. When I use a single finger on the touch screen the scene moves (pan operation) a little slower but still quite smoothly. But as soon as a second finger makes contact with the screen the scene rotation gets very choppy and unresponsive. It feels like the draw loop is blocked for some reason on the SDL events processing.

I handle events exclusively in SdlEventProc.

I initially used this code to render:

SDL_AddEventWatch(SdlEventProc, NULL);
...
while (!g_quitting)
{
    ... render ...
    SDL_GL_SwapWindow(mainSdlWnd);

    SDL_Event event;
    while (SDL_PollEvent(&event)) {};
}

But with this code I could have up to 5s delay between a two finger touch screen interaction and the scene getting rendered. Log file shows that the SdlEventProc gets called in real time as events happen but the render loop is stuck. Then about 5s later the SDL_PollEvent gets called in a loop providing a block of SDL_FINGERMOTION and SDL_MULTIGESTURE interleaved events. And after the fingers stop moving across the touchscreen the event queue is emptied the rendering continues.

If I had to guess is that the rendering is blocked while SDL is trying to figure out if a gesture is being drawn.

And another interesting thing is that if I use this code the rendering seems more responsive:

SDL_AddEventWatch(SdlEventProc, NULL);
...
while (!g_quitting)
{
    ... render ...
    SDL_GL_SwapWindow(mainSdlWnd);
    SDL_PumpEvents();
}

But from what I understand the event queue will fill up this way. Is that correct?

Since I don’t care about events in the rendering loop… Would it be OK to just flush the Event queue?
I assume SDL_FlushEvents might do the trick. But I don’t want to cause any events not getting pushed to SdlEventProc.

Since I also do not care about gesture detection… Can I somehow disable (not just filter) the gesture detection and if so - how?

I also checked if the touch screen driver is perhaps consuming all the CPU while touch operations are performed and that does not seem to be the case. The CPU load does get a bit higher (by 20-30%) but with 2 cores / 4 threads the application should remain responsive. Also hard to say what caused the CPU load to go higher and if it was indeed the touchscreen driver. The touchscreen in general is very responsive in Windows.

I am using SDL 2.0.9 at the moment. Would a newer version resolve this issue?

The problem seems to affect my Windows tablet a lot more than it affects my RaspberryPi 3.

Any ideas how to make the touch screen related lag go away?

Thank you for your time.

It’s too bad that Raspberry Pi OS ships with such a ridiculously outdated version of SDL

Uhm, that responsibility cannot be placed on RasPi folks… It’s my fault. I am afraid I may have neglected to update… cough… for a while…? :innocent:

I will update the RasPi SDL version and I just build a latest version of SDL (2.0.14) on my Windows machine and report if I SDL behaves differently.

Nah, I have a Raspberry Pi as well, and Raspbian (which is even still 32-bit unless you manually install the 64-bit beta) ships SDL 2.0.9 even when fully updated.

Meanwhile, Ubuntu for the Raspberry Pi is 64-bit and ships with SDL 2.0.14.

edit: to be fair to the Raspberry Pi people, it’s because Raspbian/Raspberry Pi OS tracks Debian Stable, which only ships “stable” packages, aka software that’s 5 years old. SDL’s auto-batching would probably greatly benefit Raspberry Pis, but it wasn’t added until SDL ~2.0.12

Batching was first enabled in 2.0.10 according to this; it’s also the version in which the float-coordinate rendering functions were added (SDL_RenderCopyF etc). Sadly there have been regressions in some recent releases of SDL2 (e.g. the SDL_RenderDrawLine endpoint anomaly) so it’s not always desirable to use the very latest ‘stable’ version.