WPF and multi touch

Please note: This article is only available in English.
WPF has some strong sides and a few weaknesses, but lately I've recognized a huge downside regarding multi-touch.

WPF has added the capability of touch events some time ago, however, even though this worked sometimes OK with Windows 7, touch events seem to be broken especially with Windows 8.

The problem lies internally. WPF does not fire such events (as a touch move, touch up or touch down) like mouse events, but differently. Mouse events are fired directly when they occur, while touch events seem to have a delay. The delay could be caused by a variety of possibilities:

  • The dispatcher wants to execute something with higher priority
  • The processing of the intermediate touch points takes too long
  • The bubbling and processing of the touch event is too expensive
  • The body of the handler takes too long and therefore is avoided

Some of those possibilities sound strange, but obviously people have made tests and it seems that indeed the WPF framework does some preprocessing on the touch events, which will cause an increasing delay. This is especially annoying if one tries to perform continuous multi-touch manipulations using WPF.

The question is: are there work-arounds? Obviously this problem is a huge drawback and does not only cause unsatisfied customers, but also disappointed developers. After all, multi-touch is sometimes nice to have or even mandatory. Right now, the answer to this question seems to be: maybe, but nothing that is a straight forward WPF solution.

I will update this when I found a proper work-around. But unfortunately I highly believe that the best choice would be to choose a different development ansatz and technology!

Update 1 Apparently the best way to get around this limitation is to host the whole WPF application in a Windows Forms context. Then one has access to the message loop. This enables a very fine grained control and allows a separation of the various events. I will post a detailed solution soon.

Update 2 The final solution was to create a layer over the WPF form. This layer had its own message loop, which was running in the usual Windows Forms (or general Windows API) context, without any truncated or modified messages. I will write a CodeProject article about this solution soon.

Created . Last updated .

References

Sharing is caring!