Flash player 30+ causing issues with our large games

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.

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.

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.

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

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.

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?