I tried with the latest AIR build but seems that works fine.
So could you please open a new bug report on this over at bugbase.adobe.com? Please include sample media, code, project or app to help us reproduce the problem. Finally, once the bug has been added would you mind posting back with the URL so that others affected can add their votes and comments?
Is it possible to send our code directly to someone from Adobe, its a rather essential part of the software we are selling and we cant have this spread on the internet. Or can we in any other way make it private only to be seen by ourselves and adobe?
We stil need to set up a working demo for you to check out but we expect to be able to set it up later this week or next week. I will inform you once we have it.
Max van knippenberg
Van: xia rao firstname.lastname@example.org
Verzonden: donderdag 13 oktober 2011 9:39
Re: Multitouch freeze
I'm runing into the same trouble.
If there are many TouchPoints at the same time, the air app freeze for about 1 sec.
We are developing a desktop game and need a quit good touch vilocity.
In Flash Player 11.1 everything works fine.
Are there any news?
Is there any news on this? I'm having the same problem, and it's a critical bug. I'm getting a demo prepared for a client on the SUR40 and AIR freezes sporadically with multiple touch points. Here are some additional things I've noticed:
When freeze occurs, if you hold fingers down on screen, the framerate drops to about 1 FPS, and CPU usage drops from 75% (for my app) to 5%.
It will stay this way until you do one of two things:
1) Lift finger(s) off the surface
2) Move the mouse pointer
For some reason, moving the mouse pointer when it's in this "frozen" state resumes the normal framerate.
It appears there's a problem with the event subsystem.
I tried to enter this as a bug, but the bug system won't let me in for some reason.
When you tried to log in, did you use the same account as you did for the forum?
What platform is this happening with for you? Any chance you could provide me (email@example.com) a sample app so I could test this out?
Thanks for the quick response! My problems with the bug system were that when I went in to it, it kept prompting me for a screen name, and never let me past that step, no matter what I entered (use case: try to enter a bug, get prompted for login, create new account, get prompted for screen name (infinitely)).
The issue with the framerate is happening on the Samsung SUR40 Microsoft Surface running on Air 3. I'm developing with Flex using Flash Builder 4.6, all the default options for SDK etc...
Scouring the internet showed me other people having the same problem. Apparently the only way to fix it is to use the flash player embedded in the browser insead of Air. Doing this fixed the issue for me, but causes other issues (can't launch in full screen at startup with flash player). So now I'm using Nodejs as a little "mini server" on the device to serve up the SWF and content.
Since this works in the browser I can move forward with Flex for this project, I just have a big button visible at startup that says "launch" which kicks everything off and puts the app into fullscreen mode.
Thanks again for your help, just FYI - since I was able to find a work-around this isn't a show-stopper. My fall back plan was to revert to using WPF, but I really didn't want to do that since I want to be able to reuse a lot of this code for Android and iOS apps. HTML5 isn't an option because multitouch only really works consistently on mobile devices with HTML5, for some reason the W3C draft recommendations haven't been implemented yet on the desktop browsers for windows (either FF or Chrome, though FF has a proprietary API available).
Thanks for the update, I apologize for the delayed response. Glad to hear you worked around this. If you run into problems in the future just shoot me an email (firstname.lastname@example.org) and we'll work on getting the bugbase login resolved for you.
Is this still a problem with Adobe Air 3.2? My company is in the process of researching development using Air on the Microsoft Surface 2.0. This problem is related to the Windows 7 Touch events right? I'm also trying to verify that you don't need any third party tuio bridge with the Surface anymore.
I took a look at the bug database, and we did have a bug with the following description that should be fixed in AIR 3.2.
The event response freezes for a while whenever SimController sends out an unexpected event.
For example, if the client swf set Multitouch.inputMode as MultitouchInputMode.TOUCH_POINT, TouchSimEvent is expected, and everything works well if user only use Click and Drag action.
But if user chooses any other action such as Pan and does some operations on Gesture layer, then switches back to Click and Drag, event responses will freezes for a while this time
FWIW, switching to running in the browser fixed the issue for me.
I just have a local nodejs instance serving everything up, and it gives me all the local IO I need. With that combo, I really didn't need AIR, and it makes deployment and updating much easier as well (I just rsync from an update server, which gives me small delta updates instead of the huge downloads AIR forces on you).
I have an icon on the desktop that launches FF or Chrome directly to the localhost URL, so there really isn't a difference to the user from an app standpoint.
Someone can confirm that it's possible to deploy an AIR touch app on the Samsung SUR40 (Microsoft Surface) ?
Are the performances great ?
We are prospecting to buy an interactive table for one client and we would like to know what is the best interactive table choice for adobe AIR ?
The SUR40 is great in many ways, but there are some key things to be aware of:
- Controlled lighting. This unit will not function under normal lighting conditions, you need to have an highly controlled lighting environment. This means no windows at all, even with blinds.
- Poor performance. If you're going to be running a CPU intensive application, this would be a poor choice. The unit ships with an underpowered AMD cpu, and as far as I know, there's no way to upgrade it.
I have a more detailed write up of my experience here on slashdot: http://hardware.slashdot.org/comments.pl?sid=2844903&cid=39979593
Thank you Clay for your precious answer !
I wasn't aware that the lighting was such a problem...
This is key for us ! The contrast ratio : 2000:1 is really too weak !
We will abandoned the SUR40 solution and look for another product.
Just by curiosity, did you try to optimise your app using stage3D (Starling framework, Alternativa 3d ...) ?
I'm not sure if this bug has been fixed. I'm experiencing exactly the same problem when publishing using the AIR 3.2 SDK and Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT; is set.
On some touch events the whole application freezes for a second before resuming (everything including the rendering stops). It seems to be fine if i touch and move quickly, but if i touch and hold for a split second in the same spot this freezing occurs.
I'm using Flex 4.6.0 & AIR 3.2
If this is related to the SimController (simulating touch events) is there any quick workaround to disable simulated touches (which i don't need) i can't afford to wait for a fix on this job as it's meant to be going live next Friday and the freezing is very obvious (it's on a multi-user multitouch table with constant animation in the background)
Yes ,this definitely seems to be the same issue - I have published to Flash player 11.2 and it works perfectly. The problem is I do need to run in AIR as it makes good use of the File class which i can't work round very easily.
Does anyone have any suggestions for an AIR fix/workaround..?
If you are targeting a desktop, I can tell you the solution I came up with works great.
1) Ditch AIR, use flex in the browser
2) Install Nodejs as a service - this can be done as part of the install process, using nssm: http://nssm.cc/
3) Create a link for the browser of your choice to launch the app, optionally headless (depending on the browser)
4) Have flex talk to node, and have simple js scripts handle all IO (node is a lot better at it anyway)
This approach has several advantages:
- It makes updating the app much easier (AIR updating is crappy, especially if it's a large installation, you can't do deltas or patches)
- It lets you use node for all the heavy lifting/IO/backend scripts, which is it much more suited to than AIR
- It fixes the multitouch freeze problem
- It gives you an architecture that lends itself to redeployment as a web-based app later, if needed.
Honestly, I went down this path originally because I needed a work-around for the multitouch freeze issue, but after doing things in this way, I don't see myself going back to AIR for really anything except mobile. Being able to have an update mechanism based on rsync to do delta patches is pretty darn nice, and being able to completely break out of all the annoying security sandbox issues and do anything I want at the node layer has sealed the deal for me.
It also gives a nice clean separation between backend service logic and UI/presentation logic, so it future proofs your code (you can just reimplement the UI in HTML5 later, if needed).
Hope this helps,
Brilliant, love it!
The app runs very smoothly with no locking up or freezing from the touch events now. Great idea using nodejs for the IO too, definitely a good solution.
It's a shame this doesn't work in AIR though, I also develop multi-screen mobile apps and this is a major blow not being able to effectively handle multi-touch. I hope it's on the fix-list for the next release.
Clay, thanks for sharing your solution!
Sean, can you enter a bug on this at bugbase.adobe.com? The bug fix I mentioned for 3.2 was either different or not fully fixed given your experience. I'd like to see this fixed too, so once the bug has been added please let me know and I'll follow up internally. If you can, please add a link to this forum thread in the bug report.
The bug has already been declared for AIR 3.2 on May 16th (ID 3191100 - https://bugbase.adobe.com/index.cfm?event=bug&id=3191100) by someone else.
I have also entered a new one (Bug 3207304) , and included a very simple test project with steps to reliably reproduce it.
Hope it gets sorted soon - thanks for your help
Please try recent 3.5 beta to see the fix for this bug. We greatly appreciate your effort on reporting the bug to us and patiently waited. If you can give us feedback after using 3.5 beta, it'll be great. Thank you!
I had the same issue on a TUIO device with windows 7. AIR 3.5 fixed the problem. Thanks!
I'm happy to hear that. We just released 3.5 this week so it's good to know your issue is solved. Thank you for your feedback!