Trouble with a Snap! project

[maryfries]

Hello,

Paul and I (both OS X 10.9.5) are having trouble accessing this project in several browsers: http://snap.berkeley.edu/snapsource/snap.html#present:Username=bjcsolutions&ProjectName=U3L1p3%20all%20SentenceBuilder%20(answer%20file)

Chrome does open it.

In Safari (PG & MF: 9.1.3 (9537.86.7.8)), it crashes the whole browser.

In Firefox (PG: 49.0.2 and MF: 48.0.1) it takes so long that it throws a popup asking if you want to terminate the script, though if you continue to run it, the file eventually loads. Here is the console output:

TypeError: aCanvas is null
[Learn More]morphic.js:1711:9
TypeError: aCanvas is null
normalizeCanvas()
morphic.js:1711
SnapSerializer.prototype.rawLoadProjectModel/project.pentrails.onload()
store.js:393
openModalWindow()
nsPrompter.js:360
ModalPrompter.prototype.openPrompt()
nsPrompter.js:550
ModalPrompter.prototype.confirmEx()
nsPrompter.js:694
BoxMorph.prototype.outlinePath()
morphic.js:5462
BoxMorph.prototype.drawNew()
morphic.js:5456
CommentMorph.prototype.fixLayout()
blocks.js:11777
CommentMorph.prototype.init()
blocks.js:11680
CommentMorph()
blocks.js:11626
SnapSerializer.prototype.loadComment()
store.js:999
SnapSerializer.prototype.loadScripts/<()
store.js:923
forEach()
self-hosted
SnapSerializer.prototype.loadScripts()
store.js:906
SnapSerializer.prototype.loadObject()
store.js:723
SnapSerializer.prototype.loadValue()
store.js:1246
SnapSerializer.prototype.rawLoadProjectModel/<()
store.js:464
forEach()
self-hosted
SnapSerializer.prototype.rawLoadProjectModel()
store.js:463
SnapSerializer.prototype.loadProjectModel()
store.js:331
IDE_Morph.prototype.rawOpenCloudDataString()
gui.js:3838
IDE_Morph.prototype.openCloudDataString/<()
gui.js:3816
Morph.prototype.nextSteps/this.onNextStep()
morphic.js:2742
Morph.prototype.stepFrame()
morphic.js:2727
Morph.prototype.stepFrame/<()
morphic.js:2731
forEach()
self-hosted
Morph.prototype.stepFrame()
morphic.js:2730
WorldMorph.prototype.doOneCycle()
morphic.js:10630
loop()
snap.html:33
[Learn More]morphic.js:1711:9

[dekrain]

You can use 3 backquotes (```) to write logs.

Your logs here

Your logs here

BTW wait a moment. I will inspect what is a trouble

[dekrain]

It's possible it's because of project's size.

[maryfries]

Thanks. If students create large projects and then can never get them back, that’s a problem that needs to be fixed.

[jmoenig]

This project opens fine without any hiccups on my old 2011 MacBook Air in Chrome, Firefox and Safari. Just sayin'

[jmoenig]

Also, you can dramatically reduce the size and thus make it quicker to load by removing unused block definitions.

[brianharvey]

So, I opened it in Safari without problem, except that the placement of things in the scripting area overlapped because I wrote this file originally in zoom blocks 1.5, and Safari didn't have that setting recorded (I never use it for Snap!). So I tried to change zoom blocks from 1 to 1.5, and /that's/ when Safari crashed. The system reloaded it, and the loading was kind of slow but successful, and formatted as intended.

The project was written in Firefox (v31) in the first place.

P.S. This is not what I think of as a large project. One sprite, no media, just a bunch of scripts and blocks, and a few small non-circular lists.

[cycomachead]

I did open fine for me in Safari as well. I didn't try zooming blocks. (Funny mine is always set at 1.5 or 2, depending on how tired I am.)

The XML shows up as 95K which doesn't seem that large either.

[jmoenig]

When we're talking about "big" projects we can't just look at the size of the serialization, but we need to consider how big it gets in memory. Inside Snap it's the blocks using most of the memory, because they are instantiated with "costumes" (bitmaps). In retina mode the size of these easily quadruples, and so it's the libraries and blocks, the custom block definitions that are blowing up the size of a project, not so much the costumes and / or sounds.

This is also at the heart of why some browsers (apparently some versions of FF) take longer than others to open a project or library.

There are several ways to deal with this, and I don't want to discuss them all here. Bottom line: This is an (important, I think) design decision and I'm happy to think about ways to mitigate these once we find some time together.

Bottom line: In Snap, code is media.

[cycomachead]

I was mostly using serialized size as a proxy for the amount of code. Yes, everything is in memory, and we're doing crazy things with canvas, but a project like this doesn't have all that much code.

There's also a variety of different issues. In Safari - crashing is likely a memory issue, but in Firefox, those script warnings are a result of execution time. There's an about:config setting that lets you up the internal limit.

[brianharvey]

Grump. I vote for deleting retina support; it's nothing but trouble.

Or at least, please, please make the checkbox remembered per-user instead of per-project! And maybe it should default to off.

[cycomachead]

Oh god no, Snap! is so much better to use with retina support. It is MUCH easier to read now.

I don't think this is a problem with retina support. We've had these problems since the beginng of (Snap!) time. Both Safari crashes and the Firefox slowness.

We are also 110% abusing the canvas apis from what they were designed for.

[jmoenig]

We are also 110% abusing the canvas apis from what they were designed for.

Really? I always thought interactive browser games were exactly what canvas was and is meant for.

[cycomachead]

Authors should avoid implementing text editing controls using the canvas element. Doing so has a large number of disadvantages:

https://www.w3.org/TR/2dcontext/#best-practices

Most canvas games are a series of Canvas and "traditional" HTML5 techniques, and in doing so browsers are more optimized for managing the structure of a traditional webpage.

[jmoenig]

yeah, but that's a rather old, non-normative "best practice", not "110% abusing the canvas apis". It only says that if you decide to implement your own text-editor in canvas you'll have a load of work.

Someone once told me that if you're following "best practices" you can't be innovating ;-)

[brianharvey]

Or at least, please, please make the checkbox remembered per-user instead of per-project!

Bump.

[cycomachead]

It's the most recent version of the canvas spec. (And non normative only refers to not following strict definitions of a few terms)

My point is that even if things work correctly at a basic level we aren't going to run into all sorts of "little" issues like this.

As far as BH's issue - that setting should be a browser level setting. Maybe we should make a new issue.

Michael Ball From my iPhone michaelball.co

On Nov 5, 2016, at 3:22 PM, Jens Mönig notifications@github.com wrote:

yeah, but that's a rather old, non-normative "best practice", not "110% abusing the canvas apis". It only says that if you decide to implement your own text-editor in canvas you'll have a load of work.

Someone once told me that if you're following "best practices" you can't be innovating ;-)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[jmoenig]

back to topic: That projects also does load fine in all current browsers on my retina MBP

[maryfries]

I tried this project in Safari Version 10.1 (12603.1.30.0.34) again today, and it loaded slowly but successfully. Firefox 52.0.1 (64-bit) also worked. :)