Flash player 30+ causing issues with our large games

[joseg24323683]

We are currently experiencing issues with performance and load times with the flash player. Seems that after Flash Player 30 was released that this issue started to happen. Our software loads a 100MB flash object which is taking about 30 seconds to load since the update happened. Since Windows 10 mandates the update to the latest flash player this is a bit out of our control. Unfortunately, Adobe is no longer doing support calls for Flash related problems. The Adobe forums is to where we were pointed to. Does anybody have a solution for this?

Related :

https://forums.adobe.com/thread/2499947

https://scratch.mit.edu/discuss/topic/303365/?page=1

[_maria_]

Sounds like you're encountering behaviour implemented to address the Spectre/Meltdown security issue.  Have you tried reenabling the shareable property of the ByteArray class, as mentioned in the 'Spectre/Meldown Mitigation' section of Flash Player 30 release notes?

[joseg24323683]

Thank you for the quick response Maria.

We added the items listed in that release note in both

C:\Windows\System32\Macromed\Flash

C:\Windows\SysWOW64\Macromed\Flash

and still experienced a long loading time. Do you have another suggestion?

[jeromiec83223024]

Adobe does not offer free support for free products.  If you have a license that entitles you to support for Animate, you could probably go through that channel for ActionScript development questions; however, this really is a pretty direct route to the Flash engineering team.

The cause and solution to the issue you're citing with Scratch is documented in the thread that you linked.

In order to mitigate the possibility that Flash could be used to exploit speculative-execution vulnerabilities in in-market Intel CPUs (recall the SPECTRE and MELTDOWN saga from last year), we had to increase the cost of calling getTimer().  That's a fundamental design change, and it's not going away.  It's not a bug.  It's intentional behavior, which was necessary to address a vulnerability in the larger ecosystem in which we exist. 

If you were calling getTimer() at a reasonable rate ( <= once per millisecond, which is the resolution of the API), you probably wouldn't feel the change.  It only shows up when you're calling it in a tight loop.

The easiest way to work around this is to simply cache the timer result so that you're only calling the underlying getTimer() call at about once per milisecond.  Since we're not updating the timer faster than that anyway, you should negate any inherent performance hit *and* shouldn't see much difference in timer resolution as a result (unless you're simulating a high-resolution timer using fancy interpolation techniques, in which case, you're out of luck).

This is exactly what Scratch was doing, and the diff that patched this in the Scratch engine is here (again, in the thread from above): Flash 30 performance changes by cwillisf · Pull Request #1396 · LLK/scratch-flash · GitHub

If that's actually your performance issue, then implementing a cached timer class should get you going with minimal pain.

If it's *not* the issue that you're seeing (which is my guess based on the fact that you disabled those mitigations -- unless your mms.cfg changes didn't really take effect), then profiling with Adobe Scout might lead you to the hotspot.  Flash Player 30 shipped in June, and beyond some really limited fallout from this timing change, I'm not aware of any insurmountable performance issues.  If you identify the hotspot and need some suggestions, we'd be happy to suggest some approaches.

If you want to double-check that you configured mms.cfg correctly and put it in the right location, you can look at the system administrator's guide, here: Adobe Flash Player Administration Guide for Flash Player | Adobe Developer Connection

There are some particulars about text encoding and file location that you'll want to pay attention to.  You might just flip a flag that leaves an obvious trace (one of the logging features, as an example), just to confirm that your settings are actually getting applied.

[MGTinckiosk]

This issue appears to be related to the activex, if we run it using the standalone flash player it loads very quick. Some background;

we load our flash through a visual basic form that contains the activex control. Like Jose stated this only started in FP 30.

Thanks

[jeromiec83223024]

Can you give us a copy of the application so that we can debug it?

[MGTinckiosk]

Are you wanting the source for our app or just the compiled version so you can load flash into it and see the behavior?

[jeromiec83223024]

Compiled binary.  I just want to find the changelist in Flash that correlates to the performance change in your application.  It's relatively easy for me to bisect the continuous Flash builds.  At that point, we should have a good idea about what the root cause is.

[jeromiec83223024]

Also, if you want to PM me with details, just hover over my name and choose Message.

[MGTinckiosk]

Just PMd you the link. Remember the issue is only with larger files.

Thank you

[joseg24323683]

We just ran a test on Windows 7 and Windows 10 with both running flash player 32 ActiveX. It performs fine on Windows 7. It does not perform well on Windows 10. We still suspect something is up with ActiveX player. It is now the end of workday over here. We will be following up tomorrow. Thank you for your help.

[jeromiec83223024]

At this point, I just need a SWF that will allow me to see the issue.  I was testing on Win7, so that may be why I didn't see it.  I'll double check, but if you have one that does the job that you can share, that would speed things along significantly.

Thanks!

[joseg24323683]

PM sent with link to file. Thanks.

[jeromiec83223024]

Thanks.  My testing indicates that this was introduced in Flash Player 31.0.0.61 (Flash Player 31.0.0.60 throught Flash Player 29.0.0.113 behaved nominally), and I've narrowed it down to a couple suspect changes between those builds.

It seems like an unintended side-effect, since neither change seem like they should impact load times at all.  There's not a flag or anything that you're going to be able to change for this.

Once we debug it, we might have some suggestions for workarounds in ActionScript or .NET, but it's possible that you may just have to wait for the fix to land in a future release.  That's most likely January's Patch Tuesday release, since we're talking about Win10.

I'll follow up with a bug that you can track in a few minutes.

[jeromiec83223024]

Here's the public bug.  I've redacted the specific details related to the content you shared with me.

https://tracker.adobe.com/#/view/FP-4198953

You probably won't see much activity until we ship a fix, since we don't have any way to provide beta builds for Win10.

[joseg24323683]

With the release yesterday (1/8) of version 32.0.0.114 we are still experiencing the same issue as before. However, on a separate machine, we have 32.0.0.101 (which I believe was released in December) the game loads quickly.

[superc51632781]

As was said by Adobe the crash should already be fixed and the upgrade to Flash 30 in Windows 10.

já deve estar corrigido e a atualização

para o Flash 30 no Windows 10.

[jeromiec83223024]

We haven't committed a fix to address the original bug at this point.  I'm not sure why it was working faster for you in the December release.  We opened the original bug after the December release shipped.

The delay is related to a change we made, which requires a click to activate Flash content embedded in all versions of Microsoft Office.