Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

DarrenEvans
Hiya,

We have a very large enterprise Flex/Flash application which makes extensive use of IBM's ILOG Elixir Gantt component.

Since Windows 10 we have, internally, experienced lag when interacting with the gantt charts so bad it made the application unusable. This was using IE11 and experienced on only a handful of machines. We noticed that the problem was not experienced if the application was run under Chrome, so for machines that had the problem we simply got the users to switch to Chrome.

However, we now have a client where the majority of their machines are exhibiting the problem. Due to strict internal software policies they cannot simply swap to using Chrome or another browser.

After investigating this a little bit, on machines with the problem, we noticed that even when the application was idle the CPU usage for IE was anywhere from 5% - 30% it would never drop back to 0%.

Hooking up Adobe Scout to the application we found that over a period of 2 seconds, while using a drag and drop operation there were nearly 9,000 tooltipChanged events fired and nearly 3,000 uodateChanged events. These events totalled ~50% of the processing time. In contrast, on a machine behaving fine, we performed the same operation and only 2 of these events got fired.

Anyone seen this kind of behaviour in Windows 10/ IE 11? Any ideas on what we could do?

Personally it seems like a FlashPlayer/IE 11/Windows 10 issue but I don't really know where to go or what to do to try and resolve this!

Kind Regards,
Darren



Reply | Threaded
Open this post in threaded view
|

Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

Alex Harui
Hi Darren,

I know your app isn't hung, but some of the principles described in [1]
might apply.

It is theoretically possible that an application gets into a situation
where it is constantly trying to validate itself and thus the CPU never
goes idle but the UI is operational.  If I were in your shoes I would not
worry about drag/drop and just see what AS is running when the app is
"idle" but CPU is still running.

HTH,
-Alex

[1] https://flexcloset.wordpress.com/2016/10/20/flex-app-hung/

On 4/3/17, 1:45 AM, "DarrenEvans" <[hidden email]>
wrote:

>Hiya,
>
>We have a very large enterprise Flex/Flash application which makes
>extensive
>use of IBM's ILOG Elixir Gantt component.
>
>Since Windows 10 we have, internally, experienced lag when interacting
>with
>the gantt charts so bad it made the application unusable. This was using
>IE11 and experienced on only a handful of machines. We noticed that the
>problem was not experienced if the application was run under Chrome, so
>for
>machines that had the problem we simply got the users to switch to Chrome.
>
>However, we now have a client where the majority of their machines are
>exhibiting the problem. Due to strict internal software policies they
>cannot
>simply swap to using Chrome or another browser.
>
>After investigating this a little bit, on machines with the problem, we
>noticed that even when the application was idle the CPU usage for IE was
>anywhere from 5% - 30% it would never drop back to 0%.
>
>Hooking up Adobe Scout to the application we found that over a period of 2
>seconds, while using a drag and drop operation there were *nearly 9,000
>tooltipChanged events fired* and nearly 3,000 uodateChanged events. These
>events totalled ~50% of the processing time. In contrast, on a machine
>behaving fine, we performed the same operation and only 2 of these events
>got fired.
>
>Anyone seen this kind of behaviour in Windows 10/ IE 11? Any ideas on what
>we could do?
>
>Personally it seems like a FlashPlayer/IE 11/Windows 10 issue but I don't
>really know where to go or what to do to try and resolve this!
>
>Kind Regards,
>Darren
>
>
>
>
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-users.2333346.n4.nabble.com%2FCrippling-Lag-Windows-10-IE11-FlashPlayer-
>IBM-ILOG-Elixir-tp14958.html&data=02%7C01%7C%7C8e7890d4552d4e67a8d808d47a6
>f071b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636268064657391557&sdat
>a=u5D2brsinVBjqsK8C4lzsc3%2BTths8%2FCMq4HF6YA4RMk%3D&reserved=0
>Sent from the Apache Flex Users mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

DarrenEvans
An interesting read and I have encountered this type of problem before. However, in all the cases I have experienced this it always behaves the same, it's never been machine specific.

The problem only occurs on some machines, connecting to exactly the same appserver, serving up exactly the same SWF file, using exactly the same FlashPlayer.

I think the IBM ILOG Elixir component is a red herring of sorts, it just happens to really show that it's lagging when interacting with bits using it.

I've now got a developer environment up and running on a machine exhibiting the problem, so it's now easier to experiment around with it.

Hooking up Scout with a proper telemetry enabled version of the product and experimenting with a part of the product on a screen which doesn't use the ILOG component I still get a constant 2-3% CPU time reported in internet explorer (a working machine reports 0%). Scout reports that 97% of the time is going into the Orange "Other" section in the rather unhelpful "Runtime Overhead" function. What does that mean?

<quote author="Alex Harui">
Hi Darren,

I know your app isn't hung, but some of the principles described in [1]
might apply.

It is theoretically possible that an application gets into a situation
where it is constantly trying to validate itself and thus the CPU never
goes idle but the UI is operational.  If I were in your shoes I would not
worry about drag/drop and just see what AS is running when the app is
"idle" but CPU is still running.

HTH,
-Alex

[1] https://flexcloset.wordpress.com/2016/10/20/flex-app-hung/
Reply | Threaded
Open this post in threaded view
|

Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

Tom Chiverton
Graphics drivers ? Maybe acceleration is disabled ?


On 06/04/17 10:24, DarrenEvans wrote:
> is going into the Orange "Other" section in the rather unhelpful "Runtime
> Overhead" function. What does that mean?

Reply | Threaded
Open this post in threaded view
|

Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

Alex Harui
In reply to this post by DarrenEvans
Hi Darren,

"Other" includes "Other (activities such as garbage collection, event
processing, and so on)"

I have seen the invalidation loop appear to be machine-specific when it is
actually size-specific.  Someone had an extra toolbar in their browser
which shrank the available size of the stage more than other machines and
that reduced size caused the loop.

If you have a debugger on it, I would just wait until the app is supposed
to be idle, then set a breakpoint on debugTickler in Application.as.  Then
single step and it should step you into all AS that is running.  I've had
that show me things that are unexpected.

Also compare memory allocation on working vs slow.  Maybe memory gets more
fragmented on the slow computer so more time is spent in GC.

HTH,
-Alex

On 4/6/17, 2:24 AM, "DarrenEvans" <[hidden email]>
wrote:

>An interesting read and I have encountered this type of problem before.
>However, in all the cases I have experienced this it always behaves the
>same, it's never been machine specific.
>
>The problem only occurs on some machines, connecting to exactly the same
>appserver, serving up exactly the same SWF file, using exactly the same
>FlashPlayer.
>
>I think the IBM ILOG Elixir component is a red herring of sorts, it just
>happens to really show that it's lagging when interacting with bits using
>it.
>
>I've now got a developer environment up and running on a machine
>exhibiting
>the problem, so it's now easier to experiment around with it.
>
>Hooking up Scout with a proper telemetry enabled version of the product
>and
>experimenting with a part of the product on a screen which doesn't use the
>ILOG component I still get a constant 2-3% CPU time reported in internet
>explorer (a working machine reports 0%). Scout reports that 97% of the
>time
>is going into the Orange "Other" section in the rather unhelpful "Runtime
>Overhead" function. What does that mean?
>
>
>Hi Darren,
>
>I know your app isn't hung, but some of the principles described in [1]
>might apply.
>
>It is theoretically possible that an application gets into a situation
>where it is constantly trying to validate itself and thus the CPU never
>goes idle but the UI is operational.  If I were in your shoes I would not
>worry about drag/drop and just see what AS is running when the app is
>"idle" but CPU is still running.
>
>HTH,
>-Alex
>
>[1]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflexclose
>t.wordpress.com%2F2016%2F10%2F20%2Fflex-app-hung%2F&data=02%7C01%7C%7Cdeb6
>d8508b37474f880008d47ccff9a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C
>636270680089849107&sdata=rXa95X1CGfVPiuEaFnesVgx3rK0xlhiYR6TufqpsK1A%3D&re
>served=0
>
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-users.2333346.n4.nabble.com%2FCrippling-Lag-Windows-10-IE11-FlashPlayer-
>IBM-ILOG-Elixir-tp14958p14973.html&data=02%7C01%7C%7Cdeb6d8508b37474f88000
>8d47ccff9a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63627068008984910
>7&sdata=nuOD%2FYIxtb21RnnFZZEuH7aryBKZtgDUT0GJ5VpydVI%3D&reserved=0
>Sent from the Apache Flex Users mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

DarrenEvans
Alex Harui wrote
"Other" includes "Other (activities such as garbage collection, event
processing, and so on)"
It's not GC (that has it's own activity which can be seen) it's the sub section activity "Runtime Overhead"

Alex Harui wrote
If you have a debugger on it, I would just wait until the app is supposed
to be idle, then set a breakpoint on debugTickler in Application.as.  Then
single step and it should step you into all AS that is running.  I've had
that show me things that are unexpected.
Now that is a great little trick I didn't know about!

Done that and its then stepping into the method staticRenderHandler on mx.Core.FTETextField.as. No call stack, it doesn't do anything, nothing is in invalidFields, so it just exits. debugTickler gets called again and we go back into staticRenderHandler.

Where do I go from here? Without a call stack I can't see what's initiating this call....


Reply | Threaded
Open this post in threaded view
|

Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

DarrenEvans
In reply to this post by Tom Chiverton
Tom Chiverton wrote
Graphics drivers ? Maybe acceleration is disabled ?
I did wonder about graphic drivers. All the machines I've seen this happen on are touch screens. However, the client's machine are not touch screen.

Hardware acceleration is on for the machines I've played around with. Ironically, searching FlashPlayer lag in google and some people solve their issue it by turning Hardware Acceleration off. On or off it still exhibits the problem.
Reply | Threaded
Open this post in threaded view
|

Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

DarrenEvans
This post was updated on .
In reply to this post by DarrenEvans
I think the staticRenderHandler is a red herring, FTETextField sets event listeners up to call that method on every RENDER and ENTER_FRAME so we'd expect that to be called all the time.

Here are some screenshots that may provide some more insight and make things a bit clearer from what I'm seeing in Scout.

The first is showing the time line for, logging in, navigating to a really basic screen and then leaving it idle. The idle time is the selected portion. See the uncategorized "Runtime Overhead" making up pretty much all the time:


The second is showing the time line for, logging in, navigating to a part of the system which has our most complicated usage of the ILOG Ganntt component, then leaving it idle. Again the idle portion is the selected section, notice how much higher the orange section is when in this part of the system. Again nearly all time in "Runtime Overhead":
Reply | Threaded
Open this post in threaded view
|

Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

Alex Harui


On 4/7/17, 4:04 AM, "DarrenEvans" <[hidden email]>
wrote:

>I think the staticRenderHandler is a red herring, FTETextField sets event
>listeners up to call that method on every RENDER and ENTER_FRAME so we'd
>expect that to be called all the time.

Yes, if you single step for a while and end up back at debugTickler, then
you saw all of the AS3 running in the frame, and it looks like there isn't
any serious work for it to do.

Of course, if you can also get a debugger on the SWF when it isn't having
the performance problem, you can compare to see if it is running the same
AS3 and rule it out.

I think the next step is to start comparing working vs non-working.
Compare the stage size.  Amount of memory.  Networking configuration.  I
would swear that Flash uses up more cycles on a slower network, but I
don't have definitive proof.

Also, are there any other configuration differences?  Screen depth,
resolution, etc?  Super-high-resolution screens could take more time to
render.

There was also some performance issues related to line drawing.  If you
draw lines with different line-joins, some line-joins because really slow.

In another case I saw, a bug kept a tiny Flash Authoring SWF they were
using for either a wait cursor or some advertising running.

HTH
-Alex


>
>Here are some screenshots that may provide some more insight and make
>things
>a bit clearer from what I'm seeing in Scout.
>
>The first is showing the time line for, logging in, navigating to a really
>basic screen and then leaving it idle. The idle time is the selected
>portion. See the uncategorized "Runtime Overhead" making up pretty much
>all
>the time:
><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>ex-users.2333346.n4.nabble.com%2Ffile%2Fn14991%2FBasic_Idle_Time.png&data=
>02%7C01%7C%7Ce29525ffb3464e48aaae08d47da72cf2%7Cfa7b1b5a7b34438794aed2c178
>decee1%7C0%7C0%7C636271604362597995&sdata=Ah3Kexnd6xb0natn7z8L2jK8eKjwnNRD
>%2BWOgpwOxrPw%3D&reserved=0>
>
>The second is showing the time line for, logging in, navigating to a part
>of
>the system which has our most complicated usage of the ILOG Ganntt
>component, then leaving it idle. Again the idle portion is the selected
>section, notice how much higher the orange section is when in this part of
>the system. Again nearly all time in "Runtime Overhead":
><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>ex-users.2333346.n4.nabble.com%2Ffile%2Fn14991%2FILOG%252520Idle%252520Tim
>e.png&data=02%7C01%7C%7Ce29525ffb3464e48aaae08d47da72cf2%7Cfa7b1b5a7b34438
>794aed2c178decee1%7C0%7C0%7C636271604362597995&sdata=%2FSaKVOT2x8xdoj6PWyE
>Ewd9MD6DA35f5feLzDDtGdEo%3D&reserved=0>
>
>
>
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-users.2333346.n4.nabble.com%2FCrippling-Lag-Windows-10-IE11-FlashPlayer-
>IBM-ILOG-Elixir-tp14958p14991.html&data=02%7C01%7C%7Ce29525ffb3464e48aaae0
>8d47da72cf2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63627160436259799
>5&sdata=FGqDrlEaQeYoCGOT0AsOOgRFnIpQXb4B0PcT1lFfKWA%3D&reserved=0
>Sent from the Apache Flex Users mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

DarrenEvans
Alex Harui wrote
Yes, if you single step for a while and end up back at debugTickler, then
you saw all of the AS3 running in the frame, and it looks like there isn't
any serious work for it to do.

Of course, if you can also get a debugger on the SWF when it isn't having
the performance problem, you can compare to see if it is running the same
AS3 and rule it out.
As you can see from the Scout screenshots, there is virtually no Actionscript code being run. It's all in "Runtime Overhead". Tracing through and working vs non-working behave the same (in terms of Debugtickler stepping into other code).

Alex Harui wrote
I think the next step is to start comparing working vs non-working.
Compare the stage size.  Amount of memory.  Networking configuration.  I
would swear that Flash uses up more cycles on a slower network, but I
don't have definitive proof.

Also, are there any other configuration differences?  Screen depth,
resolution, etc?  Super-high-resolution screens could take more time to
render.
1. Total mixture of memory configurations.
2. Networking, I doubt, I'm running it all locally on 2 separate machines, 1 with the problem and 1 without. I also connect just the client to a hosted Appserver using the same network cable (swapping in between) and 1 works, 1 doesn't.
3. The machine I have with me that has the problem is quite a high resolution monitor. I've dropped the resolution down to exactly the same as the working one and the problem persists.


Alex Harui wrote
There was also some performance issues related to line drawing.  If you
draw lines with different line-joins, some line-joins because really slow.

In another case I saw, a bug kept a tiny Flash Authoring SWF they were
using for either a wait cursor or some advertising running.
I don't think there is any manual line drawing stuff going on. Surely I'd see that in some ActionScript code being executed .

We are now getting desperate. A few more clients are now reporting the problem. Is there an official Adobe paid support process we can get going to resolve this that anyone knows of. My entry in the bug-tracker system is still at "Needs Review". We'd probably pay for an Adobe consultant to look at this!
Reply | Threaded
Open this post in threaded view
|

Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

clintm
It might be memory related.  How much memory is it using?

If it is memory related it might be IE's Enhanced Protection Mode (or lack
there of).  If this is disabled Flash Player will run as a 32 bit process
in IE.  I remember a problem where if the memory was greater than 800MB the
app would start to slow down and eventually crash to a grey screen.

Here's how you can enable it:
https://blogs.msdn.microsoft.com/asiatech/2013/12/25/how-internet-explorer-enhanced-protected-mode-epm-is-enabled-under-different-configurations/

Here's how you can check for it via javascript:
function is32BitInternetExplorer() {
return navigator.platform == 'Win32' &&
(window.navigator.userAgent.indexOf("MSIE") > -1 ||
window.navigator.userAgent.indexOf("Trident") > -1);
}

The approach I took was to warn the user that the browser was running in
32bit mode and gave them the link above to enable EPM to avoid memory
problems.

On Tue, Apr 11, 2017 at 9:43 AM, DarrenEvans <
[hidden email]> wrote:

> Alex Harui wrote
> > Yes, if you single step for a while and end up back at debugTickler, then
> > you saw all of the AS3 running in the frame, and it looks like there
> isn't
> > any serious work for it to do.
> >
> > Of course, if you can also get a debugger on the SWF when it isn't having
> > the performance problem, you can compare to see if it is running the same
> > AS3 and rule it out.
>
> As you can see from the Scout screenshots, there is virtually no
> Actionscript code being run. It's all in "Runtime Overhead". Tracing
> through
> and working vs non-working behave the same (in terms of Debugtickler
> stepping into other code).
>
>
> Alex Harui wrote
> > I think the next step is to start comparing working vs non-working.
> > Compare the stage size.  Amount of memory.  Networking configuration.  I
> > would swear that Flash uses up more cycles on a slower network, but I
> > don't have definitive proof.
> >
> > Also, are there any other configuration differences?  Screen depth,
> > resolution, etc?  Super-high-resolution screens could take more time to
> > render.
>
> 1. Total mixture of memory configurations.
> 2. Networking, I doubt, I'm running it all locally on 2 separate machines,
> 1
> with the problem and 1 without. I also connect just the client to a hosted
> Appserver using the same network cable (swapping in between) and 1 works, 1
> doesn't.
> 3. The machine I have with me that has the problem is quite a high
> resolution monitor. I've dropped the resolution down to exactly the same as
> the working one and the problem persists.
>
>
>
> Alex Harui wrote
> > There was also some performance issues related to line drawing.  If you
> > draw lines with different line-joins, some line-joins because really
> slow.
> >
> > In another case I saw, a bug kept a tiny Flash Authoring SWF they were
> > using for either a wait cursor or some advertising running.
>
> I don't think there is any manual line drawing stuff going on. Surely I'd
> see that in some ActionScript code being executed .
>
> We are now getting desperate. A few more clients are now reporting the
> problem. Is there an official Adobe paid support process we can get going
> to
> resolve this that anyone knows of. My entry in the bug-tracker system is
> still at "Needs Review". We'd probably pay for an Adobe consultant to look
> at this!
>
>
>
> --
> View this message in context: http://apache-flex-users.
> 2333346.n4.nabble.com/Crippling-Lag-Windows-10-IE11-
> FlashPlayer-IBM-ILOG-Elixir-tp14958p15026.html
> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

Alex Harui
In reply to this post by DarrenEvans

On 4/11/17, 9:43 AM, "DarrenEvans" <[hidden email]>
wrote:

>Alex Harui wrote
>> There was also some performance issues related to line drawing.  If you
>> draw lines with different line-joins, some line-joins because really
>>slow.
>>
>> In another case I saw, a bug kept a tiny Flash Authoring SWF they were
>> using for either a wait cursor or some advertising running.
>
>I don't think there is any manual line drawing stuff going on. Surely I'd
>see that in some ActionScript code being executed .

It doesn't take a lot of AS to make the player spend a lot of time on the
rendering.  You just have to make a few lineTo calls with the right
line-joins.

Did we eliminate GPU vs non-GPU rendering?

>
>We are now getting desperate. A few more clients are now reporting the
>problem. Is there an official Adobe paid support process we can get going
>to
>resolve this that anyone knows of. My entry in the bug-tracker system is
>still at "Needs Review". We'd probably pay for an Adobe consultant to look
>at this!

I'm pretty sure you can still call Adobe Support and pay for support.


-Alex

Reply | Threaded
Open this post in threaded view
|

Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

DarrenEvans
In reply to this post by clintm
clintm wrote
It might be memory related.  How much memory is it using?

If it is memory related it might be IE's Enhanced Protection Mode (or lack
there of).
Hiya clintm, thanks for responding.

We've had our fair share of memory related problems with the GCOD rearing its ugly head every know and then when a memory leak creeps in.

The app typically starts up using around 300MB when the busiest part of the system is loaded. This increases significantly as the system is stressed and more data is loaded up and/or more tabs (within the product not IE) opened up.

We've played around with 64Bit IE enabling before to eliminate GCODs from one of our absolutely huge customers.

Anyway, I thought I'd rule it out.

I enabled EPM on the machine exhibiting the problem and the problem persists. As soon as the main screen is loaded we see CPU activity in "Runtime Overhead" when it should be idle and on that machine it was at around 250MB.
Reply | Threaded
Open this post in threaded view
|

Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

DarrenEvans
In reply to this post by Alex Harui
Alex Harui wrote
It doesn't take a lot of AS to make the player spend a lot of time on the
rendering.  You just have to make a few lineTo calls with the right
line-joins.

Did we eliminate GPU vs non-GPU rendering?
Ok, was diverted on to some other stuff but this is still a major issue. Eliminated lineTo drawing and have also tried GPU vs non-GPU with no difference.

Alex Harui wrote
I'm pretty sure you can still call Adobe Support and pay for support.
By pure luck I have made contact with someone from Adobe who is trying to help us now. So hopefully something may come out of that investigation.
Reply | Threaded
Open this post in threaded view
|

Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

Olaf Krueger
I have not read the complete thread here so sorry if this is unsuitable.
Just in case you don't know it:
IBM Ilog Elixier was taken over by Rogue Wave in the past and I think the product is still supported:

https://www.roguewave.com/products-services/visualization/elixir

Olaf
Reply | Threaded
Open this post in threaded view
|

SOLVED!: Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

DarrenEvans
In reply to this post by DarrenEvans
SOLVED! (It's a bug in IE 11, but there is a workaround)

So for prosperity I thought I'd share where this ended up.

After much faffing, I managed to get into contact with an Adobe representative and we started technical liaison. After many emails, performance logs and videos we got to the bottom of it.

It's a problem localised to IE 11 / Windows 8.1+ and an accessibility bug. The FlashPlayer implements support for screen readers by traversing the display list looking for readable text. The larger the list (ours is pretty damn big) the slower this traversal is.

In Windows 7 and earlier, this accessibility API was only invoked when a screen reader was attached. IE 11 (we don't know if it's specifically IE 11 or Windows 8.1+) is always invoking this API for every frame. Coupling this processing with our processing, causes operations like drag and drop to become unusable.

Accessibility can be turned off (if this is an option for you) using the following code:

var accessProps:AccessibilityProperties = new AccessibilityProperties();
accessProps.silent = true;
root.accessibilityProperties = accessProps;
if (Capabilities.hasAccessibility)
    Accessibility.updateProperties();


We got caught out when calling this too early, resulting in root being null intermittently. Best place to call this is when the FlexEvent.APPLICATION_COMPLETE has been fired.

Apparently Flex, Flash Builder, Flash Pro and Animate CC all have publish options to enable/disable accessibility as well. However, we use none of these.

Turning off Accessibility completely sorted the problem for us. Abobe have raised this with Microsoft as a bug but whether it will be fixed remains to be seen.
Reply | Threaded
Open this post in threaded view
|

Re: SOLVED!: Re: Crippling Lag - Windows 10 IE11 - FlashPlayer / IBM ILOG Elixir

clintm
Thanks so much for reporting the solution. Glad to hear you finally got it
solved.

On Thu, May 18, 2017 at 6:51 AM, DarrenEvans <
[hidden email]> wrote:

> SOLVED! (It's a bug in IE 11, but there is a workaround)
>
> So for prosperity I thought I'd share where this ended up.
>
> After much faffing, I managed to get into contact with an Adobe
> representative and we started technical liaison. After many emails,
> performance logs and videos we got to the bottom of it.
>
> It's a problem localised to IE 11 / Windows 8.1+ and an accessibility bug.
> The FlashPlayer implements support for screen readers by traversing the
> display list looking for readable text. The larger the list (ours is pretty
> damn big) the slower this traversal is.
>
> In Windows 7 and earlier, this accessibility API was only invoked when a
> screen reader was attached. IE 11 (we don't know if it's specifically IE 11
> or Windows 8.1+) is always invoking this API for every frame. Coupling this
> processing with our processing, causes operations like drag and drop to
> become unusable.
>
> Accessibility can be turned off (if this is an option for you) using the
> following code:
>
> /var accessProps:AccessibilityProperties = new AccessibilityProperties();
> accessProps.silent = true;
> root.accessibilityProperties = accessProps;
> if (Capabilities.hasAccessibility)
>     Accessibility.updateProperties();
> /
>
> We got caught out when calling this too early, resulting in /root/ being
> null intermittently. Best place to call this is when the
> FlexEvent.APPLICATION_COMPLETE has been fired.
>
> Apparently Flex, Flash Builder, Flash Pro and Animate CC all have publish
> options to enable/disable accessibility as well. However, we use none of
> these.
>
> Turning off Accessibility completely sorted the problem for us. Abobe have
> raised this with Microsoft as a bug but whether it will be fixed remains to
> be seen.
>
>
>
>
> --
> View this message in context: http://apache-flex-users.
> 2333346.n4.nabble.com/Crippling-Lag-Windows-10-IE11-
> FlashPlayer-IBM-ILOG-Elixir-tp14958p15246.html
> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>