Has anyone come across this issue in other SDL apps? In Tux Paint (which
uses libSDL 1.2), touching the screen moves the mouse pointer and causes
a little ‘ripple effect’ (part of the touchscreen UI in Windows – not part
of Tux Paint), but the click doesn’t register (Tux Paint doesn’t receive
the mouse-down event).
Click somewhere else, and the previous click registers… though, of course,
the mouse pointer is now somewhere else on the screen.
Imagine it like this:
-
Touch a color in the palette at the bottom. The pointer moves there, but
Tux Paint hasn’t done anything yet (previous color remains selected). -
Touch the canvas to paint. The pointer moves to the canvas, but
nothing happens on the canvas (nothing drawn). However, now the
color you touched in the previous step is selected (and it plays the
’globby bucket of liquid’ sound effect). -
Touch somewhere else on the canvas. The pointer moves, but nothing is
drawn where you just touched… However, something is painted where you
touched in the previous step.
Basically, it’s like click events are ‘one step behind’. For more, see
the SourceForge.net bug report regarding the issue on Windows 7 on an
HP Touchsmart:
https://sourceforge.net/tracker/index.php?func=detail&aid=3184287&group_id=66938&atid=516295
Additionally, I just happened to come across a video posted to Vimeo yesterday
that demonstrates the Lenovo ThinkCenter m90z, using Tux Paint as an example
app. Frustratingly, the video demonstrates the exact problem described
in the bug. So I imagine it’s less of a hardware problem and more of an
SDL/driver/OS problem. (Certainly, Tux Paint isn’t doing anything funky
with events that would cause this ‘lag.’)
For what it’s worth, my 4yo son is using Tux Paint with no problems on
my wife’s Thinkpad X41, which is a stylus-driven (versus touch-sensitive)
display. (Basically, the display is a combination LCD screen / Wacom tablet.)
That’s under Kubuntu 9.04.
So – any tips or ideas regarding Windows 7, touch, and SDL? :^/
Thanks!–
-bill!
Sent from my computer