Since Adobe announced support for multitouch back in November, there has quite a bit of confusion surrounding Flash multitouch support. Recently, we downloaded an example from Adobe’s site to try out the built-in support for ourselves.
Adobe unveiled some multitouch examples using the built-in support found in the beta releases of Adobe AIR 2 and Flash 10.1 Adobe MAX back in November. A YouTube video of the presentation from Adobe MAX shows the limitations of the multitouch currently found in Flash 10.1 and AIR 2.
There is no support for multiple simultaneous gestures. In other words, you can scale or rotate, but you can’t scale and rotate at the same time. Support for “drag” is limited to a one-finger drag (using a mouse event). The Adobe Max examples show simple, single gestures and a lot of single-finger dragging.
Adobe’s limited incarnation of multitouch may work for simple applications using dual-touch systems, but it seems entirely inadequate for complex applications, multiuser apps, or for development on the growing list of multitouch devices supporting more than two points.
Here’s a video comparison that we developed using the example found on the Adobe website. It directly compares Adobe’s upcoming built-in support to that of our Gestureworks multitouch framework for Flash (available today).
We feel this video clearly demonstrates the significant differences between Adobe’s built-in support and the multitouch support provided via Gestureworks. You can try the Adobe example yourself at the Adobe’s Developer Connection and get a Trial Version of Gestureworks, and download the example apps (.zip 343K) we used in our video to see for yourself. You might also want to see the Multitouch + NUI blog which brought up concerns about Adobe’s implementation back in November.
Interesting work guys.
From my understanding though, you can use the raw native touch events/data in the new API to write your own gestures and therefore, native touch in flash can do all the same things. It is true that the built in gestures are limited, but I don’t see anything that says they’re mandatory considering you can write your own (like gestureworks does). What would be the benefit to not writing gestureworks using the native api especially since it’s only a matter of time that the api does all these things natively. It seems like some information is being left out in order to do a true comparison.
Keep up the good work!
Seth,
Thanks for the comment and it has gotten all of us talking here at Ideum about this comparison and it will lead to a few more in depth blog posts about what GestureWorks offers in comparison to what is built in.
You are absolutely right that you can write your own gestures, but isn’t that the purpose of a framework, that you don’t have to write everything from scratch? (You could write Flex or Swift3D using ActionScript in Flash, but would you?) We also have a built in multitouch simulator, an open source gesture library, and other features that Adobe simply doesn’t have.
As for it being a “matter of time” before multitouch is well supported in Flash. The very limited support that Adobe has announced will make its debut with CS5 which is currently in Beta. So when will they have proper multitouch support? Maybe CS6? So, maybe next year or in 2012 (or perhaps later) they may offer what we already have.
I think the comparison is fair, since Adobe themselves provided the example that we used. Certainly, they could have written something more comprehensive from scratch or better yet build in better support for multitouch directly into their product. The point here is they haven’t.
We’ll posting more about GestureWorks very soon. Thanks again for your comments.
Jim
Thanks for the quick reply Jim.
I’m hoping this is all being taken as constructive, as I admire your goals.
I think there was some confusion in what I was trying to imply. I think what I’m meaning to say is not that you shouldn’t develop a framework, but that you should consider creating the framework using the raw events provided by adobe (not the gestures). Meaning, take out custom event system or make a TUIO to native event system and develop the framework using the native raw touch events. I’m not sure you’ve specified why that wouldn’t be beneficial.
What you’re doing is similar to writing both a mouse event system and mouse framework when there’s already a mouse event system. So what I’m curious about is, why not use the native raw touch info, since that will become standard (just like mouse events are) and develop your framework for gestures and whatnot over that. If the argument is that people won’t be adopting the native events, it’s not true (since I know people who already are). Having a gesture framework isn’t lessened by the fact that you would be using the native event schema and therefore shouldn’t affect your goals; if anything, it should make it feel more professional.
So that’s just my honest recommendation and something you guys might want to consider. If there’s a valid reason for not doing so (other than a business decision), I’d be interested in hearing so.
I wouldn’t quite say because adobe provided the examples, that the comparison is fair (I’m not saying entirely it’s unfair either hehe). It’s kind of like neglecting parts of what’s possible and so people are getting a boxed vision of the full comparison. Saying you can’t do something, when you really can (in a different way) isn’t completely fair. I understand this is a business though and I wish you guys the best. If you ever need more feedback, don’t hesitate to contact me.
Seth,
First of all, yes, we do look at this as constructive and we welcome feedback about GestureWorks and the direction that we take this.
As far as your point about raw events provided by Adobe, GestureWorks will support connecting to to raw events very soon. That support will probably be released in the next couple of weeks. We started work on GestureWorks long before this option was available.
Using the raw events will have some benefits, as I understand it, as we can then create multitouch enable Websites with GestureWorks (with Player 10.1) In addition, we will be able to remove the FLOSC layer http://www.benchun.net/flosc/), which we use on our tables (in conjunction with Windows 7 support).
Chris Gerber our Software Architect for GestureWorks will be posting more technical information about these new developments.
I guess we can agree to disagree about the comparison. The examples Adobe provided on their website (and at Adobe Max) showed significant limitations. All of the gestures were single gestures. Rotate or zoom, but never rotate and zoom. etc.
They mention on their own Website which gestures are supported (http://labs.adobe.com/wiki/index.php/AIR_2:Developer_FAQ) and it is not very comprehensive list and again we never see gestures clustered together. We see pan and rotate, but never pan and rotate together. There does seem to be some inherent limitations here. As they state themselves on the same page…
“Gestures: Applications can listen for multi-touch events, or gesture events (not both at the same time). Gestures are the synthesis of multi-touch events into a single event.”
Thanks again for the comments.