Greetings!

We recently released what was recently known as the Scratch “Beta” player into the wild - to be the default player from now on. I want to write to let you know how this new player works and why we made the choices we did, so those of you making really complex projects can understand how the player handles different operations.

It all started when Adobe suddenly dropped support for pixel bender hardware acceleration…
This was a blow - and like many other people who write software that runs on flash, we weren't so happy about it. We used pixelbender for faster rendering of changes made by most of the graphic effects blocks – color, fisheye, whirl, pixelate, mosaic, and brightness (ghost is the only exception).



Pixelbender gave us good performance, and tons of graphics cards supported it. But when adobe turned off hardware acceleration for pixelbender, it meant the computer has to do the operation with its own processor instead of using the video card processor. On really fast computers, this isn't so bad - but on older, slower ones, it can create significant lag. If the graphic effect change is within a repeat or forever loop, it may slow things down considerably.

We decided to spend some time coming up with a different way to handle these effects, using a library called “Stage3D”. While we don't need the 3D (no no no, we're not making Scratch 3D, sorry!), we did want the hardware acceleration that came with it, so we could render graphic effects changes more quickly. This turned out to be more of a challenge than we thought. We also hoped there'd be side benefits in the form of better performance on tablets and mobile devices in the future, but those didn't pan out.

We ended up implementing a different way of rendering graphic effects (and really sprites in general) using Stage3D, but it turned out to add a lot of complexity (and therefore potential glitches) into the code. As some of you may remember from the Scratch 1.4x days, it's very difficult to get one implementation of the player code (i.e. the old java player) to behave exactly the same as another (the Scratch 1.4 editor) - this was no exception to that rule.

We ended up going with a compromise: We're keeping the regular, un-accelerated pixelbender based render path for all projects unless they use a graphic effects block (besides ghost). Once a graphic effects block (besides ghost) is dragged into the project, it changes modes and tries to render everything using the stage3D library. While this works fine for the majority of projects, it can introduce glitches and strange behavior sometimes, especially on extremely complex projects. If this happens to you, try removing your graphic effects blocks – the editor will detect the change and automatically switch back to the normal render path.

The compromise where we've ended up is, well, a compromise: If your project behaves differently when you use graphic effects blocks, try taking them out and see if the problem goes away. If possible, you can try to make your project work without the graphic effects block to see if performance improves. Unfortunately, the amount of time and energy it would take to make the Stage3D implementation path work perfectly in all scenarios is more than we can afford to spend - hence the need for this compromise.

Scratch On!

you wanted to see my os and so on: My browser / operating system: Windows 7, Chrome 33.0.1750.146, Flash 12.0 (release 0)

Cool! This really helped me understand the glitches that have been going on!

Does the detector also accept “Clear all graphic effects” ? Because i think i removed all graphic-effect blocks except the ghost blocks and clear graphic effect blocks, but all the graphical bugs do still appear

TM_ wrote:

Does the detector also accept “Clear all graphic effects” ? Because i think i removed all graphic-effect blocks except the ghost blocks and clear graphic effect blocks, but all the graphical bugs do still appear

Interesting - it would be good if we had a clear debug message we could look for in the console, to see when a mode shift has (or hasn't) occurred. I'll ping grokblah.

I was pretty confused when this started to happen, thanks for clearing it up for us

This stinks. Wasn't someone working on a JavaScript based player a while back? A player that runs in another language besides flash might be good to have.

add these blocks please:

stick to [sprite 11 v]

what it would do is the sprite would stick to that position even if (sprite 11) turns.

and

un-stick from [sprite 11 v]

what it would do is un-stick form a sprite that is already stuck to (sprite 11).



thanks!

(-re57)

P.S. it goes in the motion section

That's unfortunate. Hopefully the HTML5 player will be able to fix some of these issues!

Yes, the (ex-)beta player certainly does render incorrectly sometimes…

If you want to see how badly it can mess up, take a look at what happens in my 3D projects. For example: http://scratch.mit.edu/projects/10143939
Notice what it does to the background sky objects (stamped sprites), and the artefacts left by the transparent rects around the lens flares (not stamped).

And InterXeptor 3D is totally unplayable with the beta player.



One thing I'm curious about, though. It seems to me like it doesn't always choose the beta non-pixelbender route for certain machines. Is this because it detects the Flash version? And if it's old enough for pixelbender to work fine then it sticks with that?

I'm on a Mac, so I'd be interested to know if anyone with Windows/Linux, and who knows their machine is using the ex-beta route, can try out the projects above and let me know if it's as bad as I see (with both FF & Safari). -Thanks!

EDIT: I should also note that I detect some other differences for the beta player that don't seem related to graphics - for example, I'm wondering if it handles “wait” blocks too ‘intensively’?
The reason I say this is because it seems like “wait until”, for example, now causes more lag than having a “repeat until” loop with things happening inside it! Does this mean it's actually executing the condition check way too quickly (i.e. way more often than the usual 30x per second Scratch refresh rate)?

Lightnin wrote:

TM_ wrote:

Does the detector also accept “Clear all graphic effects” ? Because i think i removed all graphic-effect blocks except the ghost blocks and clear graphic effect blocks, but all the graphical bugs do still appear

Interesting - it would be good if we had a clear debug message we could look for in the console, to see when a mode shift has (or hasn't) occurred. I'll ping grokblah.

I'm pretty sure “clear graphics effects” does not switch on the ex-beta player.

The reason I say that is because I tried taking out a couple of effects blocks from a project I've got that goes very badly wrong in the ex-beta player. It was obvious the moment I took them out that it had switched back to the original player - various sprites suddenly looked right again (even without the project running), and everything was then working correctly when I ran it. Yet I still had plenty of “clear graphics effects” dotted all over various sprites…

However, I also have another project (Scratch Pi Calc) which appears to use the ex-beta player, despite having only a single “set ghost effect to 1” block (which I use to work around a slightly irritating off-by-one-pixel bug that Scratch sometimes has when switching costume), and even continues defiantly using the ex-beta player, even though I took out that ghost block (as well as all “clear graphics effects” blocks).
EDIT: Forget that - looks like it has switched to normal player after all…

OK, so this is probably why the graphics of this got significantly reduced…

Darn! Adobe is mean
Can't wait to see a new version of Scratch in HTML5/Canvas (Yes, I know Snap exists, I'm just giving a friendly nudge )

DigiTechs wrote:

Darn! Adobe is mean
Can't wait to see a new version of Scratch in HTML5/Canvas (Yes, I know Snap exists, I'm just giving a friendly nudge )

If you're any good at JavaScript, you can help out with it.

scimonster wrote:

DigiTechs wrote:

Darn! Adobe is mean
Can't wait to see a new version of Scratch in HTML5/Canvas (Yes, I know Snap exists, I'm just giving a friendly nudge )

If you're any good at JavaScript, you can help out with it.

Sadly, I'm not well versed in JS, so I can't help out

I could learn though, its syntax is much like a mix of Lua and Java.

DadOfMrLog wrote:

One thing I'm curious about, though. It seems to me like it doesn't always choose the beta non-pixelbender route for certain machines. Is this because it detects the Flash version? And if it's old enough for pixelbender to work fine then it sticks with that?

The primary check is for Stage3D support (and we've just added one to deal with a case where Chromebooks that are ARM are falsely claiming to be i386 - we know won't try Stage3D on chromebooks because they don't support it.) Basically, if we don't find a platform that doesn't support Stage3D, we'll stick with pixelbender whether or not it is accelerated by hardware, b/c that's the only option really.

why did Adobe drop it anyway?

dusty22 wrote:

why did Adobe drop it anyway?

They claimed that it was a security problem, but some people are skeptical of that claim. There was quite a lot of pushback on the thread where they announced it - I think there's a link to it in an earlier forum post about pixelbender.

maxuper03 wrote:

Please add this block:

(go to http://[]/)

It can open page in browser

that would be way to easy to abuse

PlasmaKairo wrote:

maxuper03 wrote:

Please add this block:

(go to http://[]/)

It can open page in browser

that would be way to easy to abuse

And it's pretty spammy and off topic too. Those kinds of requests go in the suggestions forum.