Long Scripts hit internal Canvas size limit (rendering oddities.) #997
Comments
|
I have this weird hunch something could be realted to #20 but I have no idea for sure. |
|
Interesting! Looks like a memory issue to me, maybe the GPU runs out of texture memory to create the huge bitmap (35 k pixel high!) that would be the scripting area. Scratch certainly used to have a limit for this. I did not introduce one for Snap, but it seems there is one (might be machine dependent, though) |
|
Yeah, it seems like a browser issue, since pretty much everything else works correctly. Also, try opening this project in Safari...I get browser / process crash reports on the whole project, which is a bit odd. |
|
Yes. I've got a whole list of browser issues that have been increasing lately without any changes on Snap's side. Safari has gotten very unstable and often simply crashes. I've already reported this to Apple. What's worse, Safari does the same in iOS, simply crashing and reloading the page. Turns out it's even way worse if Safari is opened locally (not via a webserver). This is a bummer, because it affects Brandon's iOS app. Ach, browsers! |
|
Yeah, also in flat design mode the background is off-write. It seems like some rendering thing. I might try to investigate but I don't know if I'll get far. |
|
OK! Got something interesting! I removed the last two scripts and the background automatically returns! There is indeed some hidden threshold, but I have't measured it yet. |
|
Ahhhh, it appears that right around 32,800 is a problem. Which I guess means, it's very like 32,768px is the max height. Edit again: Yup, 32768 is indeed the max height, everything renders find there. Edit: Stackoverflow verifies my empirical testing: So @jmoenig If you want to introduce a max height or something, I think we can leave this open, otherwise, I feel like this should maybe just be a documented limitation for now. 32K is a LOT of code in one sprite. :O |
cycomachead
changed the title
|
The one thing I did realize is that when the limit is hit, there is no context menu or anything, so perhaps a Snap! imposed limit would be good. |
|
Yeah, I wonder why that is the case, though. Inspecting the morph reveals that the bounds are, in fact, set correctly. I'm assuming that the only thing that fails is the transparency detection, because that requires access to image data. If that's true then simply changing the ScriptMorph's "noticesTransparentClick" property to "true" should solve it (which might be a good idea anyway). (... trying this right now...) Yes!! Morphic is awesome :-D So, switching to dev mode, right clicking on a block so you get the hierarchy menu you can inspect the ScriptsMorphs and simply change its "noticesTransparentClick" setting to "true", and then save it. Now you can switch back to user mode and you get the context menu again. Maybe it's a good idea to change it, as it's an optimization anyway... |
|
Oh, nice! That sounds like a good fix. That way, if you rearrange scripts you can still easily "clean up" and shrink the extra space. :) |
* fixed occasional horizontal rendering artifacts in block “holes” (C-shaped slots and Ring holes) * improved user editing of input slots and fixed cursor behavior (note: the text cursor inside input slots also blinks again, as it should have) * always export comments attached to prototype hat blocks in the block editor along with script pic * when first opening a block editor on a custom block definition make it big enough to show everything (as much as fits on the screen) * remember block editor position and dimensions for each edited custom block definition when acknowledging (pressing OK or APPLY) for the session * speed up stacking of commands and loading of projects by suppressing redundant block redraws * introducing a “grab threshold” preference to suppress accidental grabbing through micro-movements of the hand. This addresses the “cannot-click-on-drop-downs-in-Chrome-under-Windows” set of bug reports, and also the issues that arise out of accidentally dragging off a copy of a parameter blob when trying to just click on it to rename it * new hidden (shift-click) option to adjust the grab threshold in the settings menu for the current session * expand list watchers inside result bubbles and speech/thought balloons to show everything (as much of the list’s first level as fist into either the scripting area for result bubbles or the stage for speech balloons - note resizing the stage affects the size of the list watchers inside speech balloons, i.e. making the stage bigger increases the number of visible elements even while the balloon is showing) * fixed a bug that make an occasional gray rectangle appear at the mouse pointer * added a way to invoke blocks synchronously in JavaScript - under construction (possibly to be used for generic “When” hat blocks and user-customizable drop-downs) * added methods to cache morphs’ fullImage and fullBounds while dragging * Reporters (also nested reporters) and sprite icons (in the corral) are now semi-transparent when being dragged, so you can see possible drop target halos /through/ them * in “prefer empty slot drops” mode (default) it is now much harder to drop reporters onto non-static C-slots inside custom blocks (e.g. in FOR loops) and onto variadic input arrowheads (to replace the whole input with an input list) * ScriptsMorphs are now noticing transparent clicks (addresses #997) * %interaction slots are now static, fixed #982 (it is no longer possible to drop reporters into the input slot of a “When I am…” hat block (never was intended that it should be possible) * fixed ctrl-f for the block editor in all situations (thanks, Brian, for the bug report)
|
Closing this because the main error is handle-able. :) However, I have noticed that things like "script pic.." on scripts this big will report a blank image with no warnings... (this is also the case for the "all scripts pic" function). I don't know what should be done about those? We can't (easily) fix anything, but we could issue a warning. |
See Sprite (15) in this student project. It appears like things work correctly, but the background isn't being drawn.
http://snap.berkeley.edu/snapsource/snap.html#present:Username=cycomachead&ProjectName=buggy-student-MT
The text was updated successfully, but these errors were encountered: