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 < darren.ev...@allocatesoftware.com> 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. >
