Yeah well, the problem with sortof is that it drop his little mess on people and did not bother to provide context, and here the context is important, notably the hardware.
here Daniel was nice enough to explore the problem
Whenever the AIR app does not succeed in providing the FPS that you requested, Touch and Mouse (!) events will queue up.
You can reproduce this like this:
1) Set the requested frame rate to 30 (via [Swf(frameRate="30")] on top of your startup class).
2) Find a value of "count" that makes Flash sufficiently busy so that it doesn't reach those 30 fps and stays at about, say, 25 fps.
3) Now touch the screen with 5 fingers repeatedly, or click really fast with the mouse.
→ The touch events will queue up. If you enable the Windows feature that shows touch events on the screen, you'll see that even those visualizations become delayed.
4) Now change "count" so that the 30 fps are actually delivered.
→ Touch and mouse events will no longer queue up.
This means that you can avoid that the touch events queue up by selecting a "frameRate" that Flash can actually deliver!
5) To prove this, set the "count" value back to the value that delivered ~25 fps.
6) Set the "frameRate" to 20.
→ Touch events will no longer queue up.
I could recreate the same outcome with a Starling project, as well.
@stortof, you said that you created an app for a museum, so you're probably working with specific hardware (that's always equally fast). Thus, if you set the frameRate to a suitable value once, the problem should go away on all those devices. (Or, alternatively, optimize your code that the target frameRate is always easily reached.)
oh woohpiwooh ...
this is the classic Elastic Racetrack, that's not a bug it is how it works
Touch events depends on the main loop of the Flash/AIR runtime,
if you try to render graphics at a high FPS off course your events gonna accumulate on the next frame and they will queue up (as illustrated in the post of Daniel).
Event ? forgot about
try changing your FPS from 60 to 30 and then 20, see the difference in results
In the post Flash Player Mental Model - The Elastic Racetrack
see the comment from Ted Patrick
The flash player handles networking in separate threads and calls events when data returns. These calls are made outgoing within the AS portion but return to the event area. This is true with all socket based communications XML, loadMovie, LoadVars, RSO, XMLSocket, and others.
These events are interesting as they queue up in the player waiting for an event window. When the player reaches this event block, events will execute to the point of the player not being able to return within the FPS time. In effect, network operations can be defered to the next frame.
Having tested XMLSocket allot and events from this class never seem to bog down the player. You can push allot of data through XMLSocket, I have tests that push 1000 round-trip messages through the server in about 1-2 seconds. The player doesn't blink at this.
The same thing happen with touch events.
Personally I'm really tired of dev dropping their bug on different forums just because they are lazy
so far I did not see a single source code that even try to handle touch events the correct way
when you use
Multitouch.inputMode = MultitouchInputMode.TOUCH_POINT;
you do also check for
Multitouch.maxTouchPoints and you use
startTouchDrag(), it's right there in the documentation you just have to read it
but noooooooo let's drop shits on a wall and expect everything works at 60fps without doing a minimum of efforts
Touch, multitouch and gesture input
Note: Listening for touch and gesture events can consume a significant amount of processing resources (equivalent to rendering several frames per second), depending on the computing device and operating system. It is often better to use mouse events when you do not actually need the extra functionality provided by touch or gestures. When you do use touch or gesture events, consider reducing the amount of graphical changes that can occur, especially when such events can be dispatched rapidly, as during a pan, rotate, or zoom operation. For example, you could stop animation within a component while the user resizes it using a zoom gesture.
Touch event handling
Touch Point ID
TouchEvent.touchPointID property is an essential part of writing applications that respond to touch input. The Flash runtime assigns each point of touch a unique
touchPointID value. Whenever an application responds to the phases or movement of touch input, check the
touchPointID before handling the event. The touch input dragging methods of the
Sprite class use the
touchPointID property as a parameter so the correct input instance is handled. The
touchPointID property ensures that an event handler is responding to the correct touch point. Otherwise, the event handler responds to any instances of the touch event type (such as all touchMove events) on the device, producing unpredictable behavior. The property is especially important when the user is dragging objects.
touchPointID property to manage an entire touch sequence. A touch sequence has one
touchBegin event, zero or more
touchMove events, and one
touchEnd event that all have the same
If you want to use multi touch points and you don't use the touchPointID there is something wrong in your code, not an AIR bug.