My browser / operating system: Windows NT 10.0, Chrome 66.0.3359.181, Flash 30.0 (release 0)

—–

I doubt this is a Scratch bug but this seems to be the most appropriate forum for this. Since yesterday evening I found that a lot of my more CPU-intensive projects are running ridiculously slowly. These are mainly, but not exclusively, pen-based projects. It's as if everything is getting timed out in no-refresh blocks every frame. Here are a couple of my projects that were running in a frame before yesterday evening but now run at only a couple of frames per second (with the sound effects and music suffering accordingly) -

https://scratch.mit.edu/projects/227384326/ (This one is sprite-based 3D and not pen-based)
https://scratch.mit.edu/projects/226733733/

And it's not just my projects. Here are a couple of other projects that are exhibiting the same issues -

https://scratch.mit.edu/projects/169656531/
https://scratch.mit.edu/projects/220855459/

All the above projects are working fine in Edge and Microsoft Explorer (and presumably in other browsers) - just not in Chrome. They're also running fine in Chrome on other computers that I've tried them on. I know Chrome has been having speed issues on certain computers due to a Windows update recently but that particular issue didn't affect this machine. I've seen a few comments recently about projects running really slowly when they were (up until recently) running fine on this machine so I'm wondering if this is some ongoing sporadic computer-specific issue?

I've turned off all extensions, cleared the cache and cookies, etc. I can't see anything errant in the task manager (other than Chrome taking 8% of the CPU). I've run malware and virus sweeps with a variety of products (though I'm extremely careful in terms of that anyway). This does seem to be a Chrome issue, but one that's only happening on a single computer I've tested on. I'd like to know if this is affecting any other Scratchers (which I assume it is judging by some of the comments I've seen on projects recently).

—–

(Update - this computer has very recently updated to Flash 30.0 and I strongly suspect that is the source of this problem).

(Update 2 - I haven't encountered this problem on any computer running Flash 29. I have, however, just encountered this on another computer that was running Firefox with Flash plugin version 30.

(Update 3 - To prevent people mistakenly thinking that projects are laggy, I've written a small script that can be added to any project to display a warning if the newest Flash plugin is being used to view it.

Looks to me like this could be related to the Flash 30.0 release. The other computers that run the projects at the expected speed are running Flash 29. I noticed this other post addressing the same issue and they're also running with Flash 30.0

I had a quick go at isolating this issue. I originally suspected that it was only affecting projects that were CPU-intensive or that were predominantly pen-based.

Here's a link to my test project which times an empty loop running 10000 times.

It's taking around 3 milliseconds to run through that empty loop in Internet Explorer or Edge and over 1000 milliseconds in Chrome!

This seems to almost certainly be related to the release of Flash 30. We are investigating now, but it may take some time to track down what is causing this on Adobe's end.

In the meantime, you might want to use phosphorus.

thisandagain wrote:

This seems to almost certainly be related to the release of Flash 30. We are investigating now, but it may take some time to track down what is causing this on Adobe's end.

Thanks Team Scratch for Repairing

Yes! This is happening to me as I type this!

Earlier this morning, I noticed that one of my pen games was running extremely slowly, which I thought was weird because A) the project had never lagged before, and B) I'd made no changes to it since May (and the last time I'd played it, it worked fine). I played some other projects and found that they were also lagging really badly.

This seems to tend to affect projects that use the pen and perform extensive calculations, which is unfortunate since most of my major projects fit into one or the other…

-ShadowOfTheFuture- wrote:

This seems to tend to affect projects that use the pen and perform extensive calculations, which is unfortunate since most of my major projects fit into one or the other…

It affects all projects but slowing down a project that does very little processing will make less noticeable difference than slowing down a project that's already pushing the limits of what can be done in a single frame.

This test project shows it has a massive impact even when just running an empty loop

We've gotten confirmation from Adobe and they are investigating the issue. We will provide updates as we get them.

I have the same issue i hope that it will be fixed soon because i can't work on my project anymore..

bidulule wrote:

…i can't work on my project anymore..

The offline editor is working fine.

It happens to me too ! Go see these projects to test them:

- Random Plinko Generator

- Pseudorandom Bitmaps Generator With Seeds

All Scratch chess engines I tried are broken due this, as they are slowed down by a factor of 10 to 20:

• https://scratch.mit.edu/projects/2737104/
  
• https://scratch.mit.edu/projects/86498104/
  
• https://scratch.mit.edu/projects/148769358/
  

We've gotten some more info from our discussions with Adobe. It looks like these slowdowns are due to a change that was made to Flash to address Spectre / Meltdown vulnerabilities within their system. Unfortunately, this fix required Adobe making changes to Flash's Timer APIs which resulted in them becoming *much* slower. These APIs are used in a few places within Scratch, but the performance changes are very noticeable whenever you use the “timer” or “reset timer” blocks in the sensing category.

We are looking into ways to mitigate this, but given that the change from Adobe is not a “bug” this may take us some time to sort out. Rest assured we are on the case. In the meantime, we recommend using the Scratch 2.0 Offline Editor with Adobe AIR 29 or earlier if you run into major issues due to this issue. Thanks.

thisandagain wrote:

We've gotten some more info from our discussions with Adobe. It looks like these slowdowns are due to a change that was made to Flash to address Spectre / Meltdown vulnerabilities within their system. Unfortunately, this fix required Adobe making changes to Flash's Timer APIs which resulted in them becoming *much* slower. These APIs are used in a few places within Scratch, but the performance changes are very noticeable whenever you use the “timer” or “reset timer” blocks in the sensing category.

We are looking into ways to mitigate this, but given that the change from Adobe is not a “bug” this may take us some time to sort out. Rest assured we are on the case. In the meantime, we recommend using the Scratch 2.0 Offline Editor with Adobe AIR 29 or earlier if you run into major issues due to this issue. Thanks.

*Checking my shared projects*
Oh gosh… No one is working anymore…..
*looking at the project i wanted to share today*
Oh! this one too!
*Rage Quit*

thisandagain wrote:

We've gotten some more info from our discussions with Adobe. It looks like these slowdowns are due to a change that was made to Flash to address Spectre / Meltdown vulnerabilities within their system. Unfortunately, this fix required Adobe making changes to Flash's Timer APIs which resulted in them becoming *much* slower. These APIs are used in a few places within Scratch, but the performance changes are very noticeable whenever you use the “timer” or “reset timer” blocks in the sensing category.

We are looking into ways to mitigate this, but given that the change from Adobe is not a “bug” this may take us some time to sort out. Rest assured we are on the case. In the meantime, we recommend using the Scratch 2.0 Offline Editor with Adobe AIR 29 or earlier if you run into major issues due to this issue. Thanks.

As you say “These APIs are used in a few places within Scratch”.

I have found that my intensive pen projects (eg. projects that fill an area using pen) which don't use Timer or Reset Timer are all unusable with the lag issue. eg. https://scratch.mit.edu/projects/224164802/ does not work fast enough anymore to show the object consistently on the stage anymore. It draws the object in a “Run without screen refresh” custom block.

thisandagain wrote:

We've gotten some more info from our discussions with Adobe. It looks like these slowdowns are due to a change that was made to Flash to address Spectre / Meltdown vulnerabilities within their system. Unfortunately, this fix required Adobe making changes to Flash's Timer APIs which resulted in them becoming *much* slower. These APIs are used in a few places within Scratch, but the performance changes are very noticeable whenever you use the “timer” or “reset timer” blocks in the sensing category.

We are looking into ways to mitigate this, but given that the change from Adobe is not a “bug” this may take us some time to sort out. Rest assured we are on the case. In the meantime, we recommend using the Scratch 2.0 Offline Editor with Adobe AIR 29 or earlier if you run into major issues due to this issue. Thanks.

Thanks for the update, appreciate a lot that the team is on this and works with Adobe. One question, and please correct me if I am wrong, but I thought Spectre / Meltdown problems are to be fixed on a compiler (resp. operating system) level, so that opcode order is not speculative in dangerous situations. I suppose Flash is not written in assembler, so why does this require a fix in application code such as Flash (unless they work around an unpatched compiler)? OK, we should probably ask the Flash team about this.

BTW, I am also not so sure if this is only timer-related, as an empty repeat-10000-loop takes more than 1 second to execute now. At least this helped me to detect the bug in my project and show a warning, resp. prevent such loops where they are not really needed (chess engine transposition-table list filled with 256k entires).

Just maybe Adobe should include Scratch in their performance tests in the future. Millions of projects (and Scratchers) depend on it. I cannot think of any larger user group than that still using Flash today. Scratch 3.0 will not come one day too early…

thisandagain wrote:

We've gotten some more info from our discussions with Adobe. It looks like these slowdowns are due to a change that was made to Flash to address Spectre / Meltdown vulnerabilities within their system. Unfortunately, this fix required Adobe making changes to Flash's Timer APIs which resulted in them becoming *much* slower. These APIs are used in a few places within Scratch, but the performance changes are very noticeable whenever you use the “timer” or “reset timer” blocks in the sensing category.

We are looking into ways to mitigate this, but given that the change from Adobe is not a “bug” this may take us some time to sort out. Rest assured we are on the case. In the meantime, we recommend using the Scratch 2.0 Offline Editor with Adobe AIR 29 or earlier if you run into major issues due to this issue. Thanks.

The ‘timer’ block may well make the issue very noticeable, however projects that don't make any use of the timer block are brought to their knees. I don't think I have a single high profile project that will now be playable until this is addressed in some way. Even the featured project Space Gems is completely unbearable when it gets to the second gem (1st gem runs reasonably, second one 1fps on a core i7 processor?!!!).

A good example is to simply run this:

repeat (100000)

end

On the previous version of flash this runs ‘instantly’ (6/100ths of a second in fact)
However, in chrome running the latest flash it now takes 14 seconds to run.

So this simple loop is roughly 233 times slower than it was before the flash update (with no timer blocks in sight)

I noticed that on Edge browser the game graphics are running perfectly but the keys are not updating.