WPF Touch Event Fires with Delay - by CSSForumEngineer

Status : 


Sign in
to vote
ID 782456 Comments
Status Active Workarounds
Type Bug Repros 16
Opened 3/28/2013 6:52:10 PM
Access Restriction Public


Reported from http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/756a2ccf-6cf1-4e4a-a101-30b6f3d9c2c9/
It appears that TouchMove event fires quite differently than MouseMove event.
After UI being busy for a while, a lot TouchMove event will fire and reports the out-dated touch positions. These are supposed to be disagarded and available via e.GetIntermediateTouchPoints
Sign in to post a comment.
Posted by Sarath Chandran R on 3/23/2015 at 8:58 PM
Dear WPF Team, I am working on a multitouch application and currently facing a performance issue when we are having multiple touch inputs (like when using 5 fingers at a time) and makes it worse when we increase the input. The root cause seems to be due to the issue mentioned here.

I am curious to know when this bug will be resolved as we have an urgent customer facing issue.
Posted by noemata on 6/23/2014 at 10:04 AM
The other workaround is to create your own TouchDevice. Using such an approach isolates your WPF application's use of touch.
Posted by quicksb on 6/4/2014 at 8:29 AM
if you follow the workaround, YOU CANNOT LOGIN WITH A TOUCHSCREEN
Posted by Cyclade1900 on 2/17/2014 at 6:16 AM
I don't... I can't even....

I completely agree with the other developers. Not addressing this bug is like telling people to stop developing touch applications for Windows. The touch performance is unacceptable, and for developers to have to create workarounds is just outrageous. I will not even consider making a touch application for windows 8 untill this bug is fixed.
Posted by clarksbrother on 2/12/2014 at 8:25 AM
Agree with the below - this is a HUGE bug. You can't expect developers to take you seriously Microsoft if you ignore something as important as touch interfaces...
Posted by Daniel Kornev on 10/22/2013 at 1:30 PM
This is a really huge bug. I double sanfrancesco's word that this bug makes it practically impossible to build touch applications with acceptable performance on WPF.
Posted by sanfrancesco on 6/3/2013 at 9:15 AM
Dear WPF Team, this is not a side issue. It is impacting a great deal of WPF developers, as a search for "WPF touch slow" on Google will illustrate. It practically makes it impossible to create a touch application with acceptable performance on WPF, we had to sidestep WPF and implement Win32 touch events instead. The only reason you're not hearing much of this is that most coders affected by this issue will move directly to IOS or Android.
Posted by Microsoft on 3/29/2013 at 11:11 AM
The WPF team has recently reviewed this issue and will not be addressing this issue as at this time the team is focusing on the bugs impacting the highest number of WPF developers. If you believe that this was resolved in error, please reactivate this bug with any necessary supporting details.

We appreciate the feedback. However, this issue will not be addressed in the next version of WPF. Thank you.
–WPF Team.
Posted by Microsoft on 3/29/2013 at 12:10 AM
Thank you for submitting feedback on Visual Studio and .NET Framework. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Microsoft on 3/28/2013 at 7:51 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)