Why is Adobe AIR running on Windows 10 experiencing performance issues?

[Jens_OS]

Hi everyone

At my company, we are using Adobe AIR for quite some time now to create desktop multi touch applications.

When testing our software in Windows 10 preview builds, we encountered issues with multi touch where touch points would get stuck. Luckily, this issue turned out to be a Windows 10 issue and was solved in one of the last preview builds. So the issue was fixed before the official release of Windows 10.

Because we were happy our software worked, we deployed it on some Windows 10 machines.

During the time we have done this, we discovered Adobe AIR is having performance issues while using multiple touch points. We already know Adobe AIR queues touch points when it has to process much information, but this issue has different symptoms.

I researched what could have been the cause of this performance hit. 3 different computers have been used to compare the results. Specs for the computers can be found at the end of this post.

My conclusion is that Adobe AIR is experiencing performance issues running under Windows 10.

Reasons why the problem probably resides in Adobe AIR:

• One of our Unity applications is not having any performance issues. The computer load is more distributed across CPU and GPU within Unity.
• The performance becomes worse the more processor intensive objects are placed on the stage (videos vs images). Example from our Win10 computer: the systems starts lagging when there are a couple of videos and 7 touch points are used to move them around. When doing this with images, everything runs just fine. On a Windows 7 machine, it takes much more touch points before the computer starts lagging.
• The issue started arising from using the latest Intel Nuc computers running Windows 10. Of course these machines already start lagging when using 5 touchpoints regardless of the objects on the stage. So we have tested on a more powerful computer to figure out if the issue is caused by hardware.
  We have a simple AIR test application to see if touch is working. We have a processor intensive 'brush stroke' that can be used to push the machine to its limits and see when it starts to lag. When comparing the old Win7 Nuc with the more powerful Win10 Acer Veriton, they started to lag around the same amount of touch points (15). This is worrying as the Veriton processor is faster, has more cores and is a newer generation processor. If everything would be fine, you would at least expect the Veriton to be able to handle more touch points before starting to lag.
• One of our applications where the issue emerged, places a couple of objects directly on the stage. My first instinct was to look if any of the objects had outrageous specs (e.g. an image that is 8000 x 8000 pixels), but this was not the case. We also have not had any issues with this application before on Windows 7 machines.

I have not created a bug report yet because I want to know if some of you have had the same experience and if any of you might have found a workaround or good practice to boost the performance when it comes to multi-touch within AIR running in Windows 10?

We are using the Adobe AIR 4.0 SDK. We know this is definitely not the latest version, but are not able at the moment to change everything to the latest version because of various dependencies regarding the development of our software.

Computers we have used:

An Intel Nuc

- Windows 7 Pro 64 bits (6.1, build 7601)

- Intel Core i5-3427U @ 1.80GHz 4 CPUs, ~2.3GHz

- 4 GB RAM

- Intel HD Graphics 4000, memory 1760MB

- 30 touch points screen

An Acer Veriton

- Windows 7 Pro 64 bits (6.1, build 7601)

- Intel Core i5-2320 @ 3.00 GHz 4 CPUs, ~3.0GHz

- 4 GB RAM

- AMD Radean HD 6570, memory 3809MB

- 10 touch points screen

An Acer Veriton

- Windows 10 Pro 64 bits (10.0, build 10240)

- Intel Core i7-2600 CPU @ 3.40GHz (8 CPUs), ~3,4GHz

- 6GB RAM

- AMD Radeon HD 6570. memory 4850MB

- 64 touch points screen

Yours sincerely,

Jens Wouters

[Jens_OS]

We have done a test today with Adobe AIR SDK 19 and the same issues are present.

[Jens_OS]

A bug has been added to the bugbase:

Bug#4081695 - Multi touch in Win10 experiencing performance hit compared to Win7

[Kratika Agarwal]

Hi,

We have checked this issue on win 7/win 10. The AIR app gets hanged after some time when videos and images are placed on the stage.

This issue occurs in both win 7/win 10. Couldn't see any difference, As you say on win 7 it takes much more time to start lagging, but I couldn't  see hanging delay in win 7 compared to win 10.

In the bug#4081695, could you mention any one scenario for which I can verify the difference in behavior of the AIR application in both OS.

What I tried in the shared application is Adding a video, and adding images.

Please mention steps to reproduce the issue of a particular non-working scenario or through which difference in hang start time could be noticeable in both OS.

Thanks

[Jens_OS]

Thank you for the quick response. We are looking into a way to create a particular scenario and we will send an update once we have created one.

[Jens_OS]

We have created a specific scenario. The description has been added to the bugbase, as well as a newer test application that gives some more info to the user.

Bug#4081695 - Multi touch in Win10 experiencing performance hit compared to Win7

[mike_cobb]

I know this is a fairly old post, but I'm experiencing the same issues & would love to see Adobe investigate.

[davidrenelt]

This issue almost cost me my client. We developed a Multitouch application with object tracking (via multiple touchpoints). Since it's not a perfectly stable thing, touchpoints get lost and found often. Because of that bug the events queue up very quickly and make Adobe Air unusable. The solution was to run the thing on Windows 7 ... seriously .. my client wasn't very pleased and i will not dare suggesting Adobe Air ever again. Researching i realized that this bug is years old by now, I'm glad to have found a "solution" and i'm getting paid, but the damage to my reputation is done.

[zwetan_uk]

It is more likely the issue is a touch driver issue with Windows than anything else.

Not all touch screens are of the same quality, compare a high-end one with a low-end AND with the exact same machine,

and there you will see differences.

What is mentioned in the OP is true: "Adobe AIR queues touch points when it has to process much information"
but the cause is not within AIR, it is due to how well the OS can process the touch events,

when you have bad drivers it is "slow" and the events have a tendency to accumulate at each event loop

and after some time it does create lag, when the drivers are good the touch events are processed on time

and AIR consume them smoothly.

[davidrenelt]

we have 4 different touch screens from different vendors, 2 are infra red, 2 are capacitive. the issue is reproduceable on all. The problem occurs only in Adobe AIR, other touchapps (html based) are unaffected. The issue is with windows 8 and above.

So given that its a prob specific to window touch drivers and Adobe Air .. why would microsoft care to do anything. It's not affecting anything else from what our research could find. So it is specific to adobe AIR.

And .. it's a known thing: https://forum.starling-framework.org/topic/windows-multitouch-problem

There is an entry in the bug base for years now. There is just no willingness to even adress it. So i don't see how Adobe is not at fault here.

[zwetan_uk]

davidrenelt  wrote

And .. it's a known thing: https://forum.starling-framework.org/topic/windows-multitouch-problem

yeah if you actually go to the end of that thread you will see that the general advise is to get the latest touch screen drivers

so the known thing is not that AIR have an issue but that bad/outdated touch screen drivers cause problems

my other point is to say that an high-end touch screen (which cost more money)
would have higher quality and up-to-date drivers and with those you don't have any issues

so out of your 4 different touch screens, I would say check if the vendors provide updated drivers

you would have the same problem on tablet, a low-end Android tablet that cost $200
does not have the same touch quality than a higher-end Apple tablet in the $1200+ range

don't expect miracle with software only, when the hardware can not keep up

[davidrenelt]

Dude, you have no idea what you are talking about. This is annoying that i feel obligated to clarify any further, but here it goes: The bug can be reproduced on ANY touch device under window 8 or above. Windows tablets, Noteboots with touchscreens .. you name it .. it doesnt matter. Most touch devices don't even come with specific touch drivers as the architecture is fairly standardized. So in 8 out of 10 cases touch screens just run on the default windows touch drivers. But that doesn't even matter .. with or without vendor drivers the result is exactly the same.

If you only have one ore two fingers on the screen and/or flash isn't in trouble to balance code executing and rendering you won't feel a thing, but if you have 3-4 fingers doing things at the same time and the issue starts. Events get pushed back and queued.

The touch screens we are using are these: Multi-Touch Monitor - Interactive LCD Screen | MMT Alvaro

(the 4K 65") they go at around 5000k $. But we have tested this on a wide array of TouchScreens with different software (we are developing apps for a convention with 10 different touch apps in different form factors, so we have access to a very big assortment of different touch technologies atm.

Any other plattform is unaffected, unity, .net HTML .. those are the ones we tested, but this is enough to assume that Adobe AIR is at fault. Talking to the vendor they don't see how it can be anything but Adobe Air at fault, as this issue is unknown to them with any other tech.

I personally put in a lot of research trying to save my skin .. because i suggested Air .. so it's on me. If it wasn't for the Windows 7 solution, i would be out of a job now. If i would have been able to pin this on anything but Air .. believe me .. i would have, and i would have come out of this with my reputation intact.

[gfantiniAqua]

davidrenelt​

At this point in time, zwetan is the only human being on earth who doesn't recognize Adobe's fault on this matter. I've been doing multitouch development on desktop AIR for the last 15 years and I can confirm everything you're saying. This obvious performance issue:
- Does not happen on Windows 7.
- Has been plaguing Windows since version 8.
- Does not happen on Windows 8/10 with any other development platform.
- Happens with every single touch sensor I've laid my hands on (dozens).

It actually shocks me that zwetan can't see how this is definitely something only Adobe can fix. He's a smart, experienced AIR developer. And as opposed to what he said, the aforementioned thread on the Starling forums does not end with a simple recommendation to update drivers. It goes on and offers insightful info on the possible root causes of the issue. No need to say it all points to the AIR runtime.

I've personally done my fair share of contribution trying to push Adobe to look into it. But I feel I'm hitting my head against the roof at this point. You can give a little nudge yourself by visiting the links below and describing your own experience. Maybe someone at Adobe will notice.

https://github.com/Gamua/Adobe-Runtime-Support/issues/37

https://tracker.adobe.com/#/view/AIR-4081695

[davidrenelt]

I'm sorry to say so, but this thing was such a close call for me that i wont touch Adobe AIR again. I've been developing for it for roughly 15 years also, but in recent years it becomes actually dangerous to even suggest it to clients. It all works out if in the end i could show, Flash can do all the things you want and most of them better then other tech .... but .. the moment something goes wrong it's on you. When we use Unity and we run into some quirk .. we can just say .. hey thats a quirk of Unity, can't help it .. lets find a workaround. Same goes for HTML5/WebGL. The pure fact that those are perceived as "new" while flash is perceived as old makes it an increasingly hard sell.

Now bugs like this, specially the fact that it is years old now finally crushed the little confidence i had. I knew that the tech is dead for years now, and I mostly moved on to other tech, but for some jobs i'm just a lot quicker with Flash/Adobe AIR and that i was able to publish the same thing on iOS and Android from the same codebase is in some cases a real money maker. But now the corpse starts to smell and i rather accept the quirks of other tech then ever having the "what .. you are using that dead horse" discussion ever again.

[gfantiniAqua]

Yeah, I hear you. I'm still using AIR simply because our flagship application is one of those cases where the platform is a perfect fit. Yet. But the way Adobe has been handling it over the last few years does make me very worried.

I mean, I don't really care about not employing shiny new tech, as long as whatever I'm using is a better choice. And I still think it is the case. For me. For now. But it's really more complicated when you're developing bespoke apps and have to explain why you picked a given platform. So I can't blame you.

When a bug of such impact remains at a "to test" status for years, one starts to wonder if Adobe actually gives a crap about us users. Now, suppose this is not a bug at all as zwetan insists, I guess we deserve at least a response with an explanation. Heck, even if it's an "unfixable" bug, we would still deserve an official statement.

Hello Adobe… anyone there?

[zwetan_uk]

davidrenelt  wrote

...

The touch screens we are using are these: Multi-Touch Monitor - Interactive LCD Screen | MMT Alvaro

(the 4K 65") they go at around 5000k $. But we have tested this on a wide array of TouchScreens with different software (we are developing apps for a convention with 10 different touch apps in different form factors, so we have access to a very big assortment of different touch technologies atm.

...

I personally put in a lot of research trying to save my skin .. because i suggested Air .. so it's on me. If it wasn't for the Windows 7 solution, i would be out of a job now. If i would have been able to pin this on anything but Air .. believe me .. i would have, and i would have come out of this with my reputation intact.

OK, so if you do check out MMT support and search for drivers
Support - MMT - Manufacturing, Methods & Technology - MultiTouch Monitors and transparent LCD device...

oh surprise (such a shocker) they use "PQLabs Touch Frames"
and if you check them

https://www.pqlabs.com/support-touch-screen.html

not only you will be sure to have the latest drivers: release date 20180803

but you will be able to find also demos (oh my god some done with Adobe AIR)
and even SDK that you can actually integrate with AIR

but sure you've done a lot of research and I don't know what I'm talking about

[davidrenelt]

zwetan_uk  wrote

but sure you've done a lot of research and I don't know what I'm talking about

yup Have a nice day.

[zwetan_uk]

so that's it?
you're reviving a 2015 old post just to say "oh AIR is so bad it almost cost me a client"

maybe you programmed it wrong?

I have plenty of counter-opposite examples where everything works great

[gfantiniAqua]

Yes, everything works great. Until it doesn't. I have experience with hundreds of PQ Labs frames from different generations and every single one of them presents all of the aforementioned issues. In fact, I have a screen right next to me with one of those frames, and no matter what driver version I use, I can reproduce every symptom.

You're getting it all wrong, zwetan. The recommendation to update drivers is only good for a specific case where touches sometimes get stuck. But this bug does not affect PQ Labs sensors. Those demos and SDKs you mentioned are old as hell. In fact, they came out in the Windows 7 era (not surprisingly).

My AIR app works very well under Windows 10, provided the user doesn't perform specific gestures. Which sucks. Now, these very same gestures don't do any harm in Windows 7.

Why? That is the question you don't seem to be able to answer.

So we're programming it wrong for Windows 10, but right for 7. But isn't it the same runtime? Please enlighten me.

[davidrenelt]

He is obviously only invested in being "right". At not point he tried to even understand the issue tho it is rather well documented in that starling forum thread. So I see no point in arguing with someone like that.

If your touch app only needs to handle 2-3 fingers at a time, there is no issue (or rather its so minor that people just dont know how snappy it could be if it wasn't for that bug), so that is probably why there is little incentive for Adobe to acknowledge the issue at all. And even in simple test apps where the code execution isn't pushed back by the rendering, you can show that multiple touch points work reasonably well.

In our case we have two physical objects that get detected by 4 touch points each on the table, and the application is designed to be handled by two people. So in the minimum state we have 8 touch points to handle, in the worst case its 10-12. The slowdown of the events gets so serious that it's not workable at all. Windows 7 was the solution, we have 0 issues there. Also interesting to note is that only the touchBegin and touchEnd are affected, as long the touch point is active, the touchMove event triggers as expected without being qued up, which should have everyone's head explode as this event gets fired a lot and in rapid succession.

Damn, why am i still writing here I really have to switch off notifications .. i'm done with this. It's one thing that Adobe is letting this tech fade, it's also the total lack of a community and dudes like zwetan here that are the nail in the coffin for me.

[zwetan_uk]

davidrenelt  wrote

He is obviously only invested in being "right". At not point he tried to even understand the issue tho it is rather well documented in that starling forum thread. So I see no point in arguing with someone like that.

I have only advised to update your drivers but apparently this is "too hard"

you seems to be more interested in complaining about Adobe AIR
and going into personal attacks about people who do not not agree with you

from my experience, good developers are looking for solutions to problems

and bad developers love to blame anything and anyone else for their own issues

good luck with that

[davidrenelt]

You missed the fact that i told you i did update drivers, not only that, i've tried different versions to see if there is any change.

All you came up with so far is "yer doing it wrong". In your mind that seems to be sufficient for keeping up a conversation about a bug. At no point you commented on any of the information provided. For example one of the key witnesses: it doesn't happen on Windows 7. I'm actually curious about your explanation.

- The Bug is well documented

- There is no solution for it

- There has not been any attempt on Adobe's side to even comment on it

And now it gets funny: Show what you think is a "personal attack", and why you think it's one. It's going to be very telling

[davidrenelt]

Just found your videos from another thread trying to demonstrate the non existence of the bug. You need to do two things to show it doesn't exists. Your test app needs to create a descent load in the render pipeline, throw a video in the background or something that keeps the renderer busy like an animation that gets triggered by an "enter_frame" event. It also makes a difference if there is GPU accelerated elements. With pure software rendering it's a lot less, tho still noticeable, but it takes more load for the bug to occur.

Secondly you need to create and remove touchpoints in rapid succession. so instead of just moving your touchpoints, continually put 10 fingers on, remove, put on .. you will see that those start to lag behind. The touch_move event is unaffected.

btw.. you can see the delay even in your video at the end. Look at what rate the "touch_end" events list in your app when there is rendering going on and how it affects rendering.

multi touch test 3 - YouTube

[gfantiniAqua]

I'll make it easier for you, zwetan: add a simple, endless animation in the background and provide me a copy of that app (no source code needed). I guarantee you I can induce a massive framerate drop to that animation with a very simple two finger gesture. In fact, to make sure it's not hardware dependent, I'll record that on two different machines, one with a capacitive touchscreen and one with an infrared one (with latest drivers, of course). If I don't get back to you, you win. And if you don't accept the challenge, well… That's also telling.

[zwetan_uk]

first you're missing the point, it is an hardware problem

second, I have no time nor interest in measuring any appendage in some childish challenge

feel free to tell anyone that I'm wrong and I know nothing

woopihoo that will surely solve all your problems

I'll keep using AIR for touch and other kiosk app though