We've all realized that Scratch 2.0 lags more than in 1.4, but even when viewing projects online it's very slow. I have a little story here.

I typically use Internet Explorer 10; works pretty well, and I'm on an Intel Core i3 Processor, with a lot of RAM. Projects in the project editor lag quite a bit, and on the project page a little bit. The other day I was on a different computer, an older one with an Intel Core 2 Duo Processor: pretty old by now. Not only was the computer old, but the monitor was new, touch-screen, and very high -resolution! Old computer, high-resolution monitor, aren't best friends. That is usually a large cause of lag. Anyways, I was on Scratch, full-screen web browser, which was, and importantly, either Internet Explorer 8 or 9, and was viewing one of my projects not in the editor, but on the project page. The project had no lag whatsoever, and it's not a small project; it has 500 vector costumes. Every project I viewed had no lag; it reminded me of Scratch 1.4 days.

I thought, “That's odd. Why would an old computer with an old processor, on a high-resolution monitor, run so smoothly?” Later, when I was on my usual computer, newer with a lot of RAM (I think 5 Gigabytes, if that's a lot, but I'm sure it's more than the old computer), the project on the project page lagged a lot. Why is this? I think I have found out, and have proof to back it up.

The reason the project ran so smoothly on the old computer was thanks to an older Internet Explorer glitch. On Internet Explorer 8 or 9, or whatever I was on, I noticed that when I would click “See Inside” it didn't just flip to the project editor in-game; it reloaded a whole new web-page of the project editor. When I was in the project editor, the project lagged a ton on the older computer. Then, when I went to click back on the project page, it had to reload a whole new url to the project editor (not a new tab). In summary, on the old IE, both the project page and editor were not simultaneously opened; they were not one Webpage, but two separate ones, unlike the other browsers.

After studying (not really), I came to the conclusion that on the old computer, it lagged more in the project editor than the new one, but it lagged much less on the project page. Why? Because there was a glitch in the old IE where the project page and project editor were separate webpages, and were not opened up in unison. Basically, whenever any of you view a project on the project page, the whole editor is there but just hidden. I know this because you can tell if you check the project editor's webpage code (not the JSON, but HTML code), and also if you're on the project page viewing a project, when you switch to the editor it won't restart the project.

So what's my suggestion? Definitely to make the project editor and project page separate web pages. I seriously think that is the main reason why Scratch lags. On that old IE they were separate, but not on newer browsers. When one or the other is hidden, it still causes a lot of lag. Why did the project editor lag more on the old computer? Because that's the most powerful part of the web-page. The project page isn't as powerful (I'd assume). So when the project page was opened on the old computer without the editor opened and hidden, it ran smoothly. But the newer computer had both opened at once.

Think about the project page. The entire editor is hidden behind it, so Adobe Flash has all those actors and clones of blocks and a paint editor and sound editor all there simultaneously. With the editor closed, the project just simply runs on Adobe Flash text codes, and about 151 lines of HTML code. Pretty simple and much less lag. When in fact having the editor open at the same time has, I'm guessing, thousands of lines of code. The old website didn't have a whole editor opened the same time because it was offline. Please support this and post your thoughts! I'd also really like to hear what a Scratch Team member has to say about this.

Again, my summed up suggestion is to have the project page and editor separate webpages, in which are loaded completely separately and not together in one webpage.

I know that's a lot

Edit: Below a Scratch Team member confirmed that both the editor and project page are opened together, and one is just hidden while the other's showing.

I support!

For those who are like “tl;dr”, the above says that the project viewer and editor are on the same page. So to fix this is to load the editor seperately from the viewer.

I support this fully.

Why not? Support.

Sure thing. Support.

EDIT: This seems to be the 10,000th topic on the new Forums! Look at the URL.

I only support this because it's the 10000th topic.

Epicness123 wrote:

it's the 10000th topic.

:O

OH GOD. SUPPORT.

I knew IE would pull through eventually. A moment of silence please :')

On my computer it loads quickly enough. Info in my sig.
Perhaps it should test the loading time, then set a month-long cookie for people who have this problem. I like how it loads quickly instead of loading a whole other webpage.

Hi, Turkey3.

Thanks for noticing this and posting your observations. It's a reasonable theory about running the player on a separate page, but even when running on a separate project page, all the editor facilities are still there, they are just hidden. There is only one Flash program that does both project playing and editing. As you noticed, it has to do a LOT more work when it is editing, so editing is slower.

There's definitely a clue here, but there are a lot of variables: graphics card, the exact versions of IE and Flash, the interaction of Flash with the web browser, etc. Do you have access to the older computer that had less lag? If so, it would be helpful to know the exact versions of IE, Flash Player, and Windows.

You can use this link to find out which version of Flash is running:
http://helpx.adobe.com/flash-player/kb/find-version-flash-player.html

It would also be great to have the URL's for a few projects that run obviously faster on that computer. Ideally, the lag would be noticeable immediately even by someone unfamiliar with the project.

I believe there may be several different lag problems. One problem that I've been able to reproduce (but not solve yet) seems to be specific to Chrome (or possibly the version of Flash built into Chrome). The symptom is slow/delayed/jerky response to keyboard events, such as you find in many games. But the lag only appears in certain projects and I haven't yet figured out what's special about those projects that causes it. But the projects with this problem run smoothly in all my other browsers (all of which run Flash 10.3.183.86). Did the lag problems you notice involve keyboard input?

I've also seen some bad redisplay problems with certain versions of Safari 5. Fortunately, those bugs were fixed in later versions of Safari, and I don't think many people still run the buggy version of Safari. That bug was so bad that Scratch was totally unusable.

The graphic effects were unusably slow on one model of Samsung Chromebook (the 300 series). For example, color change effect was 20 times slower on that model than it was on the apparently almost identical Samsung 500 series Chromebook. That turned out be be related to the processor on that particular model, which was an ARM-architecture. Many of the graphic effects in Scratch use the Adobe “PixelBender” image processing engine but that engine was never ported to ARM. (This particular problem is unlikely to affect most Scratch 2.0 users.)

Thanks again for reporting your observations. I definitely want to make Scratch 2.0 run as fast and smoothly as possible, and this could be an important clue.

– John

I wonder if the editor lag has something to do with the glow around scripts…

johnm wrote:

Hi, Turkey3.

Thanks for noticing this and posting your observations. It's a reasonable theory about running the player on a separate page, but even when running on a separate project page, all the editor facilities are still there, they are just hidden. There is only one Flash program that does both project playing and editing. As you noticed, it has to do a LOT more work when it is editing, so editing is slower.

There's definitely a clue here, but there are a lot of variables: graphics card, the exact versions of IE and Flash, the interaction of Flash with the web browser, etc. Do you have access to the older computer that had less lag? If so, it would be helpful to know the exact versions of IE, Flash Player, and Windows.

You can use this link to find out which version of Flash is running:
http://helpx.adobe.com/flash-player/kb/find-version-flash-player.html

It would also be great to have the URL's for a few projects that run obviously faster on that computer. Ideally, the lag would be noticeable immediately even by someone unfamiliar with the project.

I believe there may be several different lag problems. One problem that I've been able to reproduce (but not solve yet) seems to be specific to Chrome (or possibly the version of Flash built into Chrome). The symptom is slow/delayed/jerky response to keyboard events, such as you find in many games. But the lag only appears in certain projects and I haven't yet figured out what's special about those projects that causes it. But the projects with this problem run smoothly in all my other browsers (all of which run Flash 10.3.183.86). Did the lag problems you notice involve keyboard input?

I've also seen some bad redisplay problems with certain versions of Safari 5. Fortunately, those bugs were fixed in later versions of Safari, and I don't think many people still run the buggy version of Safari. That bug was so bad that Scratch was totally unusable.

The graphic effects were unusably slow on one model of Samsung Chromebook (the 300 series). For example, color change effect was 20 times slower on that model than it was on the apparently almost identical Samsung 500 series Chromebook. That turned out be be related to the processor on that particular model, which was an ARM-architecture. Many of the graphic effects in Scratch use the Adobe “PixelBender” image processing engine but that engine was never ported to ARM. (This particular problem is unlikely to affect most Scratch 2.0 users.)

Thanks again for reporting your observations. I definitely want to make Scratch 2.0 run as fast and smoothly as possible, and this could be an important clue.

– John

Unfortunately, it was a public computer, so I don't know the specs. I know it was a Core 2 Duo, Windows 7, HP monitor if that matters.

I noticed less lag on
http://scratch.mit.edu/projects/10461714

An this next project is where I really noticed this. It's a 500 frame snowball fight animation, vector graphics. On the old computer, it ran, on the project page, phenomenally smooth, with a high frame-rate. In the editor, it was terrible. It was like 5 frames per second with terrible lag. On the new computer, it ran faster in the editor, but slower on the project page.

Snowball Fight

johnm wrote:

Thanks for noticing this and posting your observations. It's a reasonable theory about running the player on a separate page, but even when running on a separate project page, all the editor facilities are still there, they are just hidden. There is only one Flash program that does both project playing and editing. As you noticed, it has to do a LOT more work when it is editing, so editing is slower.

But how are all the editor facilities still open but hidden even when the editor and player have separate pages? Obviously the player must use Scratch's code to run the project, but why must the facilities of the editor be running?

Nothing is being edited… that's like if Microsoft Visual C++ had to run in the background every time I used a program written in it…

turkey3 wrote:

johnm wrote:

Hi, Turkey3.

Thanks for noticing this and posting your observations. It's a reasonable theory about running the player on a separate page, but even when running on a separate project page, all the editor facilities are still there, they are just hidden. There is only one Flash program that does both project playing and editing. As you noticed, it has to do a LOT more work when it is editing, so editing is slower.

There's definitely a clue here, but there are a lot of variables: graphics card, the exact versions of IE and Flash, the interaction of Flash with the web browser, etc. Do you have access to the older computer that had less lag? If so, it would be helpful to know the exact versions of IE, Flash Player, and Windows.

You can use this link to find out which version of Flash is running:
http://helpx.adobe.com/flash-player/kb/find-version-flash-player.html

It would also be great to have the URL's for a few projects that run obviously faster on that computer. Ideally, the lag would be noticeable immediately even by someone unfamiliar with the project.

I believe there may be several different lag problems. One problem that I've been able to reproduce (but not solve yet) seems to be specific to Chrome (or possibly the version of Flash built into Chrome). The symptom is slow/delayed/jerky response to keyboard events, such as you find in many games. But the lag only appears in certain projects and I haven't yet figured out what's special about those projects that causes it. But the projects with this problem run smoothly in all my other browsers (all of which run Flash 10.3.183.86). Did the lag problems you notice involve keyboard input?

I've also seen some bad redisplay problems with certain versions of Safari 5. Fortunately, those bugs were fixed in later versions of Safari, and I don't think many people still run the buggy version of Safari. That bug was so bad that Scratch was totally unusable.

The graphic effects were unusably slow on one model of Samsung Chromebook (the 300 series). For example, color change effect was 20 times slower on that model than it was on the apparently almost identical Samsung 500 series Chromebook. That turned out be be related to the processor on that particular model, which was an ARM-architecture. Many of the graphic effects in Scratch use the Adobe “PixelBender” image processing engine but that engine was never ported to ARM. (This particular problem is unlikely to affect most Scratch 2.0 users.)

Thanks again for reporting your observations. I definitely want to make Scratch 2.0 run as fast and smoothly as possible, and this could be an important clue.

– John

Unfortunately, it was a public computer, so I don't know the specs. I know it was a Core 2 Duo, Windows 7, HP monitor if that matters.

I noticed less lag on
http://scratch.mit.edu/projects/10461714

An this next project is where I really noticed this. It's a 500 frame snowball fight animation, vector graphics. On the old computer, it ran, on the project page, phenomenally smooth, with a high frame-rate. In the editor, it was terrible. It was like 5 frames per second with terrible lag. On the new computer, it ran faster in the editor, but slower on the project page.

Snowball Fight

Bump

When I pressed “See inside” on a project with scripts running, the project continued from that oint in the Editor. Very nice and helpful, especially if you just want to mess with a level on a platformer and do't want to take all that time to get back to it.

However, it doesn't work the second time, because exiting Editor reloads the whole page.

turkey3 wrote:

I noticed less lag on
http://scratch.mit.edu/projects/10461714

An this next project is where I really noticed this. It's a 500 frame snowball fight animation, vector graphics. On the old computer, it ran, on the project page, phenomenally smooth, with a high frame-rate. In the editor, it was terrible. It was like 5 frames per second with terrible lag. On the new computer, it ran faster in the editor, but slower on the project page.

Snowball Fight

The first one made my Shockwave Player crash (although admittedly, this happens quite a lot and I had another tab open). The second one, however, went perfectly fine even at full speed. I think it has to do with the browser. (I'm using Chrome.)

@johnm:

If it helps, I put together this lag test project a while back:

http://scratch.mit.edu/projects/10125047

It has a number of comments from various people, containing behaviour under various conditions, and specs for machine/flash/browser.

Regarding the key-event problem on Chrome (and other browsers, too, but not usually quite so bad), I've found it's made much worse if the project is taking longer between refreshes than the standard Scratch loop timing of 1/30th second. (That's why I've forced the lag test project to spend 1/8th second in a non-refresh block every ‘frame’.)

DCPU-16 noted the same in this topic a while back: http://scratch.mit.edu/discuss/topic/2135/

It's also clear that having key-repeat set very fast can exacerbate the problem (in certain browsers - esp. Chrome), while switching it off completely can often turn a project from seriously unplayable into quite smooth. So that suggests some kind of issue with event buffers.

Hope that helps a bit!

Bump. Somebody else please post your thoughts.

Listwizard wrote:

When I pressed “See inside” on a project with scripts running, the project continued from that oint in the Editor. Very nice and helpful, especially if you just want to mess with a level on a platformer and do't want to take all that time to get back to it.

However, it doesn't work the second time, because exiting Editor reloads the whole page.

Yes, this is nice, but me personally I'd rather wait a few more seconds for Scratch to load between the editor and project player in exchange for better performance.

BUYP up your post.

Support.