Touchscreen delay

[Greg.Mildenhall]

There's a long-standing problem with the WM_TOUCH message that Windows uses to notify applications of touchscreen events. I'll explain how the issue affects us:

When the "Press and Hold" gesture is enabled, it will send a right-click message when the user presses and holds a point on the screen for a certain length of time (maybe about half a second). But this means that when the user first touches the screen, _no_ message is sent because it's not sure yet whether it will be a Press, Drag or Press and Hold. It doesn't send anything until either the touch is released or the timeout is reached (or perhaps until the drag is far enough?). This means that by the time the system informs the application that a Drag is happening, it reports a new touch location that could be quite far from the first point of contact half a second ago. This makes it very hard to drag small objects because your finger won't be on the object anymore by the time the Drag triggers.

There are various workarounds out there, and Unigine should offer at least one of them. For Windows 8 and above, the best way is to use WM_POINTER instead which doesn't suffer the same problem. Before Windows 8 you have to use the Gesture interface to get the information you need earlier or to switch Hold and Press off and fake the right-clicks yourself. Whichever approach you opt for, don't forget to apply it to InterfaceWindow also!

[silent]

Hi Greg,

Thanks for the advice. Btw, did you have time to debug this issues with Widgets and touch screen more closely on your side? Maybe if you already have a fix we can apply your patch to our codebase as well?

Thanks!

[Greg.Mildenhall]

The problem with widgets in an InterfaceWindow not receiving touch inputs seems obvious: InterfaceWindow has its own window_proc() callback that ignores WM_TOUCH messages rather than processing them like the window_proc() in AppWindow does. It should be a five minute fix for whoever designed InterfaceWindow and knows how everything's supposed to be structured.

It might take me a lot longer because I don't know how AppWindow and InterfaceWindow are designed to work together, and there's little guarantee my solution would adhere to the proper structure and be/stay generally usable for other people. But if you don't have anyone maintaining InterfaceWindow then I'll probably end up doing it and I'll try to remember to post about it.

*Edit: it's definitely not something I'll spend time on before we've upgraded to 2.6

Edited January 19, 2018 by Greg.Mildenhall

[silent]

Hi Greg,

OK, thanks for the update. We would definitely take a look at this when we will have touch screen monitor for proper debugging.

[silent]

Hi Greg,

Could you also give us some additional info:

1. Operating System version (are you using Windows 7 or 8+)?
2. Only widgets behavior needs to be tuned (overall 3D scene interaction is OK for you)?
3. How critical is that feature (should we fix it ASAP and send patches) or it can wait until the next release (in a couple of months)?

Thanks!

[Greg.Mildenhall]

1. We have users on Windows 7 through 10. We're phasing out 7, but we're not there yet. Still, I think we can live without fixing the delay issue on Windows 7 (we can work around it somewhat, it's just very annoying) but we definitely need to fix the InterfaceWindow bug for all platforms. (which looks to me like it will be a simple, cross-platform solution anyway)

2. For the delay issue, 3D scene interaction is important too. We use the touchscreen for terrain panning and an annotation feature that draws onto the terrain. Both have an annoying lag when you begin a dragging movement. In particular, you can't accurately place the beginning of your line in drawing mode, because the first reported contact point can be as much as half a second into the dragging action. (As for the InterfaceWindow bug, we haven't tried putting a 3D scene in an InterfaceWindow and aren't planning to, but I expect anyone who did would find it has the same problem as the widgets.)

3. We need to receive touch events in InterfaceWindows for our upcoming release which should be a matter of weeks. As I said, I'll otherwise be forced to make something up myself if I don't get an implementation from you in time, but that will likely result in more pain integrating everything back to work with your fix when it arrives. The delay issue we have workarounds for, but would appreciate a patch as soon as you have one because I'd anticipate it involving an API extension that we'll have to put in some work migrating to.

Thanks Silent.