Then my answerHi Simplesi,
Unfortunately, most of the bottleneck appears to be due to problems with X drivers for rPi. We may push a small / smple change that will improve things a little. But it's looking like it's up to the rPi team to sort out the issues.
then lightin againI'm not too bothered about the basic speed issues as I'm quite realistic over the differences between Scratch on a 3Ghz PC and Scratch on an 700Mhz arm
Its the issues like - no jpg backgrounds will load, the simultaneous key press locking and of course the most blatant speed one - the variable display update.
As "little people" we don't know who is doing what (and when )
MathsWhizz has provided a fix for variables but I feel there are probably some other objects (list???) that might need fixing as well and although you allow for mods that don't affect basic Scratch appearance/functionality to still be called and used as Scratch - it would be VERY nice to have a "sanctioned" version
I personally, will be introducing the Rpi to Age 9-11 primary children in 1 weeks time and we are going to start using it as a robot controller (programmed in Scratch of course) - it'd be nice to know that a modifed image would be available by half-term (end of October )
Ah! I didn't know there were so many issues. Most of them probably are due to issues with the squeak-vm (on which Scratch runs). But what is the bug reporting strategy for raspbian / rPi?
I'd imagine it would be good if someone could figure out the best place to report bugs. Probably it's in Debian, but I don't know enough about rPi / Raspbian to say that with confidence. If you could sort that out, and start filing bugs and give us a link to the tracker, it'd be a big help.