#160 Touchscreen Issue: One Step Behind the Clicks

In both windowed and full screen modes, using the touchscreen results in a behavior where the last action taken isn't completed until the next time you click the mouse, constantly in a state of being one click behind.

It seems that the HP Touchsmart series of computers has an added layer of touch mechanics for the touchscreen that are designed to play nice with Windows (and most applications), but Tux Paint is not configured to receive these unique instructions. I cannot find a way to disable the unique layer of touch mechanics (essentially reducing the touch screen to a basic mouse-style input). My first generation Touchsmart did not suffer from this problem, so I know it is due to the added layer of touch controls for the Windows 7 operating system.

If your developers could figure out what instructions my version of Windows 7 with its special touch interface are being sent to Tux, I am sure this issue could be resolved.

Example workflow with this issue.

1. Click on a new color. The click registers the "Click" actions on screen (little ripples, the hand moves to the touched location) but the Tux Paint interface does not register the click.

2. Click and drag in the window to begin painting (typical behavior of my three-year-old). Nothing happens on the canvas, but the last click to select a new color is registered and the color is now selected.

3. Three-year-old believes the last color was defective and clicks on a new color. A small dot of the previous color (not the one she just clicked on) appears on the canvas in the last location of the mouse cursor prior to the new click command.

4. Repeat steps two and three over and over, with the canvas receiving dots of colors without ever drawing a line.

5. Eventually I get her to try drawing a second time with the color that isn't working (because it wasn't actually selected until she clicked in the canvas). So after that initial click and drag in the canvas (which resulted in the previous click becoming activated), she picks up her finger and begins to attempt to draw again. An instant line appears from the last location of the cursor when she let up from her first click and drag all the way to the place where the new click and drag operation began, and the drawing can finally begin at this point.

6. Each successive click and drag operation is connected by that line drawn between the last point of the previous click and drag and the first point of the new one.

Obviously, the click operations are arriving at Tux Paint's code at least half a step behind schedule.

All other software I have used so far does not suffer from these problems with the touch screen.

[William Kendrick]

Thanks for the note, Brian. Are you using the latest version of Tux Paint? (Your report lists 0.9.14 Windows, but the latest for Windows is 0.9.21c, which is a minor update to 0.9.21 from mid-2009.) Are there options anywhere on your system for adjusting how tap events are handled by the touch screen?

Tux Paint gets its input events from the Simple DirectMedia Layer library (libSDL), so it might be useful to know whether other SDL-based apps are affected. Since Tux Paint isn't doing anything 'special' with events, I'm guessing the issue is at the library- or OS-level.

In any case, since it sounds like it's Windows-specific, assigning to John P. who maintains the Win32 ports of Tux Paint.

Most of my other games are SDL-based. Try Circus Linux! is a good example because the main menu is controlled by the mouse, and it can be played with the mouse: http://www.newbreedsoftware.com/circus-linux/ Otherwise, just check here for other programs you can try: http://www.libsdl.org/games.php or http://www.libsdl.org/demos.php

[John Popplewell]

Hi,

Can you try starting Tux Paint from the command-line (DOS command shell) but
first set an environment variable?

Something like this:

c:\Program Files\TuxPaint>set SDL_VIDEODRIVER=windib
c:\Program Files\TuxPaint>tuxpaint.exe

The other value to try is:

c:\Program Files\TuxPaint>set SDL_VIDEODRIVER=directx
c:\Program Files\TuxPaint>tuxpaint.exe

I'm wondering if the DirectInput stuff is the cause of the problem. The default SDL video driver may have changed (it certainly has at least once before).

cheers,
John.

[William Kendrick]

I just discovered this video demonstrating Tux Paint on the Lenovo ThinkCenter m90z touchscreen system (and it seems to be running on some modern version of Windows): http://vimeo.com/20065038 and just from watching the video, I could tell that they were having the same 'one step behind' clicking problem.

[William Kendrick]

Posted a note regarding this issue (pointing to this bug, as well as the Lenovo ThinkCenter video) to the libSDL mailing list. I realize Sam Lantinga is hard at work on SDL 1.3, but perhaps someone else out there has seen this issue crop up under the combination seen here (touchscreen, Windows 7, SDL 1.2 library).

http://lists.libsdl.org/pipermail/sdl-libsdl.org/2011-February/079679.html

[William Kendrick]

Also confirmed on Lenovo X220 tablet running Windows 7 (64bit) with Tux Paint 0.9.21c.

[William Kendrick]

Note: The Lenovo also has a stylus, which does not have the same problem as the touchscreen (using your fingers).

[Shane T Mueller]

I have experienced the same issue in my SDL program (pebl.sf.net). This is on two different touch netbooks running Win7, from two different vendors. Setting the driver to directX seems to improve things a bit, but it is still pretty spotty. It seems like the first touch moves the cursor but doesn't forward the click event. I'm wondering whether the second unprocessed event is in the event queue and could brought up with an extra call to SDL_Pumpevents(). I'll monitor this bug in case you find a resolution.

[Pere Pujal i Carabantes]

Managed to reproduce on an android tablet connecting with android-vnc to my debian laptop, which in turn runs a vboxed w7
The problem disappears when upgrading SDL.dll to the 1.2.15 version.
Would be nice if somebody tests an upgrade of SDL on a native windows device.
http://www.libsdl.org/release/SDL-1.2.15-win32.zip

[Pere Pujal i Carabantes]

As reported in the user mailing list, an upgrade of SDL solves this problem too on windows.
http://sourceforge.net/mailarchive/message.php?msg_id=30750341

[William Kendrick]

It might be worth it to repackage the current version of Tux Paint, using the newer version of SDL.

In the meantime, I've posted this issue, and the solution posted to the list today, to the Known Issues page: http://tuxpaint.org/docs/known_issues/

Thanks!

[Topbanana]

Have just experienced this problem. Unchecking the 'hide mouse cursor for touch screens' option seemed to solve it. Tux Paint 0.9.21c (using the bundled SDL lib) under both Windows XP 32-bit and Windows 7 64-bit on a 50" NEC touchscreen.

[William Kendrick]

I haven't heard reports of this lately, so I think it's moot nowadays. Closing.

[William Kendrick]

Apparently still a bug, per a report by Marcel Maier on Facebook. The word-around mentioned by @Topbanana back in 2013 apparently helps. Reopening this ticket (but hopeful that updating to SDL 2.0 will solve it), and added a note to the Known Issues page on the website.

[William Kendrick]

Can someone please test an SDL2.0-based version of Tux Paint to confirm whether or not this is still a problem? (Tux Paint 0.9.28 for Windows, and for RHEL 7 and 8 (but not 6) use SDL2.0.) Thanks in advance!

[William Kendrick]

Various folks have reported back that this is not happening for them with the SDL2 version under Windows, so closing this ticket.