ejolson
Posts: 2425
Joined: Tue Mar 18, 2014 11:47 am

Scratch 1, 2 or 3

Tue Jan 22, 2019 9:19 pm

I read in another post that it takes 70% of the available CPU just to drag a block into a program using Scratch 3 on the Pi. This would seem to rule out either the Pi or Scratch 3 as an attractive programming environment for children, especially since many children are less forgiving than many adults when it comes to lagging performance.

If it's true that Scratch 3 is required for cross-platform compatibility with Windows PCs, then Raspberry Pi seems unsuited for graphical programming until better performing hardware is available.

If a cross-platform graphical programming language that runs in the browser is not required, maybe more energy should be put into Scratch 1, NuScratch and other technologies that perform well enough to allow a child to experience some reward for their coding efforts.

Along similar lines, how much funding and effort would it take to create a purpose-built graphical code editor along with a LLVM-optimized SDL backend for displaying that animated cat?

To prevent graphical programming from becoming a frustrating experience of poor performance unable to make even simple games, it would appear something other than Scratch 3 on existing Raspberry Pi hardware is needed.

While this post may appear negative, after acknowledging this performance problem the main objective is to open a discussion how to solve it. Any ideas? Is there an alternative graphical programming language that is speedy and works well on the Pi? What would it take to make one?

timrowledge
Posts: 1157
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Scratch 1, 2 or 3

Wed Jan 23, 2019 10:40 pm

ejolson wrote:
Tue Jan 22, 2019 9:19 pm
If it's true that Scratch 3 is required for cross-platform compatibility with Windows PCs, then Raspberry Pi seems unsuited for graphical programming until better performing hardware is available.
A substantial part of the problem here is that NIT for whatever strange reasons decided that they had to have a system that 'works' in a web browser. I understand that in some school systems the teachers cannont install any software and thus anything they need t ouse has to be web based. In other jurisdictions I hear that network access is essentially banned and thus the teachers have to have local software. Logic does not seem to rule here.

The original Scratch was written in Squeak Smalltalk which *used* to work ok within a browser but quite a few years ago the collected 'wisdumb' of the web community resulted in changes to browsers that prevented this from working and there has been no way to solve that - to the best of my knowledge, anyway. So we get stuck with Flash and javascript, possibly two of the worst possible options conceivable.

Meanwhile, the Squeak based Scratch was massively upgraded to the NuScratch we all know and love (well I do, and I'm the only one that matters) but abandoned when the RPF decided to break all sane rules and allow Flash on the Pi. Now that Scratch2 is out, at least that indignity can be forgotten after a suitable period of head shaking disbelief.
ejolson wrote:
Tue Jan 22, 2019 9:19 pm
If a cross-platform graphical programming language that runs in the browser is not required, maybe more energy should be put into Scratch 1, NuScratch and other technologies that perform well enough to allow a child to experience some reward for their coding efforts.
Well there's the rub, isn't it? The big advantage that PI has is that the OS can have whatever is needed pre-installed and thus the whole "teachers can't do that" thing is a non-issue. NuScratch still runs very nicely and does its thing (except that the current kernel appears to have maybe broken the camera interface - I'm working on that) but suffers from there being no online project repository for it. MIT has completely removed all support for old project files. I don't imagine it is beyond the wit of humankind to come up with a suitable project repository.

Some enhancements to NuScratch would be beneficial - handling of the new blocks that got added, some UI changes, a new release of the Squeak VM (because of fixed bugs and performance improvements since 2016) and connection to the aforementioned new project repository. I'd be happy to contract to do that.
ejolson wrote:
Tue Jan 22, 2019 9:19 pm
Along similar lines, how much funding and effort would it take to create a purpose-built graphical code editor along with a LLVM-optimized SDL backend for displaying that animated cat?
MIT just did that; look at the result. In practical terms you won't get faster than Squeak for a complex graphical system like Scratch. It's waaaaay more than merely dragging some pictures around.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

hippy
Posts: 4348
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Scratch 1, 2 or 3

Thu Jan 24, 2019 12:16 am

ejolson wrote:
Tue Jan 22, 2019 9:19 pm
I read in another post that it takes 70% of the available CPU just to drag a block into a program using Scratch 3 on the Pi.
On a 3B I tested it used 70%-plus all the time, even when idling. It was a little sluggish but not infuriatingly so, at least for me. But I'm not their target market and wouldn't use it for coding with.
ejolson wrote:
Tue Jan 22, 2019 9:19 pm
Along similar lines, how much funding and effort would it take to create a purpose-built graphical code editor along with a LLVM-optimized SDL backend for displaying that animated cat?
There are ongoing efforts at MIT to create an off-line editor as there was for Scratch 2. That may perform better but I don't know. That is already available for Windows 7 and upwards but there is no public schedule for when that will be available for Linux or the Pi.

I am quite surprised at how much CPU Scratch 3 requires when it's simply idling and would imagine there would be better ways to have done it. I thought these 'web frameworks' were all meant to be event driven so I'm not sure why it's so active all the time. Maybe it's a simple fix to reduce CPU usage, maybe it isn't.

It probably needs someone interested in making Scratch 3 work with less CPU usage, and work on the Pi, to take a look at it. I'm not sure who that person would be but have heard the Foundation may have expressed an interest in helping MIT deliver the off-line editor.

ejolson
Posts: 2425
Joined: Tue Mar 18, 2014 11:47 am

Re: Scratch 1, 2 or 3

Thu Jan 24, 2019 2:39 am

timrowledge wrote:
Wed Jan 23, 2019 10:40 pm
NuScratch still runs very nicely and does its thing (except that the current kernel appears to have maybe broken the camera interface - I'm working on that) but suffers from there being no online project repository for it. MIT has completely removed all support for old project files. I don't imagine it is beyond the wit of humankind to come up with a suitable project repository.
It would be nice for someone, maybe the Raspberry Pi Foundation, to create a project repository to share NuScratch projects. I think this is important because

1. MIT does not do this.

2. The Raspberry Pi does not work well with the most recent MIT Scratch 3 code base.

3. There are enough Raspberry Pi users that a NuScratch project repository could easily contain sufficient projects and activity to be interesting.

User avatar
Botspot
Posts: 59
Joined: Thu Jan 17, 2019 9:47 pm

Re: Scratch 1, 2 or 3

Fri Jan 25, 2019 3:35 pm

The constant CPU usage in Scratch 3 is WebGl rendering the stage. WebGl does not support graphics acceleration on the Pi yet, so it uses the CPU instead.
To edit a Scratch 3 project, simply kill WebGl from the task manager. The stage will freeze, but dragging blocks becomes buttery smooth. Once WebGl is disabled, Scratch 3 truly becomes event based; I've seen 0% CPU with 2 Scratch 3 websites running at the same time.

To re-enable WebGl, refresh the page.
Most people don't think for themselves much anymore. 
Their brains run single core at a speed similar to a Pi 1. Then they go out and purchase smart devices to help them think. Ridiculous!

Not me, I voided my brain's warranty bit due to overclocking.

Return to “Scratch”