Block serialization compression #1031

kchadha · 2018-04-06T20:15:14Z

Resolves

#194

Proposed Changes

This is the last of the save/load work. This pull request covers the following changes:

New list limit of 200k items per list.
Make sb3 format more compact. This includes:
- serializing the following block opcodes into a more compact form ([number representing opcode, info about the opcode, (in one or more elements)]:
  - math_number
  - math_positive_number
  - math_whole_number
  - math_angle
  - math_integer
  - colour_picker
  - text
  - event_broadcast_menu (this is the shadow block used in broadcast menus)
  - data_variable
  - data_listcontents
- reducing duplication in how our data is structured, for example removing serialization of the id-uid pair in the blocks, which were previously stored as:
```
blocks: {
    'this is my long uid for my block' : {
         opcode: 'a cool block'
         id: 'this is my long uid for my block'
         ...  more stuff here ...
}
```
Added serialization and deserialization for custom state such as tempo, volume, and video related state

Note: Monitor serialization/deserialization is not covered by this work.

Reason for Changes

Making serialized 3.0 format smaller.

Test Coverage

Existing save/load tests pass. New test cases for the 3.0 format to be added in the near future.

Related PRs

scratchfoundation/scratch-parser#32
scratchfoundation/scratch-gui#1738

… shadow if they are the same, reduce duplication of information.

…a WIP since we don't deserialize blocks serialized in this way.

…st' block if trying to add to a list that is already at the limit.

… in a target that has been 'flattened' via JSON.stringify.

…the default project in gui.

thisandagain

This looks really good. Thanks for documenting this so thoroughly. 👍

towerofnix · 2018-04-07T18:17:33Z

Out of curiosity's sake, what's the purpose of limiting a list to 200k items? Sure, that's an absurdly huge amount that I doubt will ever cause issues! But I'm curious anyways. Were gigantic lists causing problems?

kchadha · 2018-04-09T13:40:45Z

@towerofnix That's a good question! In 3.0, we are changing the way we store projects on the server to allow bigger projects. There are currently some projects in 2.0 that have very long lists (some for games, but others just to test the limits of a project's size). We want to continue to support these projects, but given that we'll be able to save and load much bigger projects in the future, we don't want to also allow even bigger lists because this will increase browser memory usage while attempting to run one of these projects (or display a monitor for these lists, or scroll through the blocks flyout, etc.). Ultimately, this would cause more browser crashes, which we want to avoid. We're hoping that a 200k limit is a good balance where most projects that currently use large lists (games, etc.) still run well, but we're not actively giving way to crashing more user's browsers.

rschamp

Looks great overall, thanks for all the explanatory comments!

src/serialization/sb3.js

    obj.opcode = block.opcode;
+    // NOTE: this is extremely important to serialize even if null;
+    // not serializing `next: null` results in strange behavior


src/serialization/sb3.js

    obj.topLevel = block.topLevel ? block.topLevel : false;
-    obj.shadow = block.shadow;
+    obj.shadow = block.shadow; // I think we don't need this either..


src/serialization/sb3.js

+            }
+        };
+        primitiveObj.topLevel = false;
+        // what should we do about shadows


src/sprites/rendered-target.js

-            'ON-FLIPPED': 'on-flipped'
+            OFF: 'off',
+            ON: 'on',
+            ON_FLIPPED: 'on_flipped'


…hadow blocks.

…lower case.

cwillisf

Looks good!

src/serialization/deserialize-assets.js

        assetType = storage.AssetType.ImageVector;
-    } else if (costumeFormat === 'png') {
-        dataFormat = storage.DataFormat.PNG;
+    } else if (['png', 'bmp', 'jpeg', 'jpg', 'gif'].indexOf(costumeFormat) >= 0) {


src/serialization/sb3.js

@@ -1,13 +1,15 @@
 /**
 * @fileoverview
- * Partial implementation of a SB3 serializer and deserializer. Parses provided
+ * An SB3 serializer and deserializer. Parses provided


src/serialization/sb3.js

-    obj.inputs = block.inputs;
-    obj.fields = block.fields;
+    obj.inputs = serializeInputs(block.inputs);
+    obj.fields = serializeFields(block.fields);
    obj.topLevel = block.topLevel ? block.topLevel : false;
    obj.shadow = block.shadow;


src/serialization/sb3.js

@@ -69,17 +306,22 @@ const serializeCostume = function (costume) {
    // but that change should be made carefully since it is very
    // pervasive
    obj.md5ext = costume.md5;
-    obj.dataFormat = costume.dataFormat;
+    obj.dataFormat = costume.dataFormat.toLowerCase();


…udio engine present. This is analagous to costumes getting loaded even if there is no renderer present.

cwillisf

👍 to the sound change, too!

Honyant · 2019-03-22T03:17:33Z

@towerofnix That's a good question! In 3.0, we are changing the way we store projects on the server to allow bigger projects. There are currently some projects in 2.0 that have very long lists (some for games, but others just to test the limits of a project's size). We want to continue to support these projects, but given that we'll be able to save and load much bigger projects in the future, we don't want to also allow even bigger lists because this will increase browser memory usage while attempting to run one of these projects (or display a monitor for these lists, or scroll through the blocks flyout, etc.). Ultimately, this would cause more browser crashes, which we want to avoid. We're hoping that a 200k limit is a good balance where most projects that currently use large lists (games, etc.) still run well, but we're not actively giving way to crashing more user's browsers.

My problem with this is that my only way past this limit, which I need for like a video playback thing is to use a method that combines multiple lists, which is harder to manage and expand. So either way, it will crash the browser, so I think lists should still be given infinite length or at least be given an option to do so.

kchadha · 2019-03-22T14:54:26Z

@Honyant, this pull request was merged almost a year ago, so any new conversation on here will not be easy to track. Please feel free to create an issue for your request.

kchadha added 16 commits April 6, 2018 11:33

Block and variable compression. No need to serialize uid of block and…

334058b

… shadow if they are the same, reduce duplication of information.

Some block serialization compression -- compress primitives. This is …

21d6060

…a WIP since we don't deserialize blocks serialized in this way.

Deserialize compressed primitives.

d61ea23

Use bitmap asset type and 'png' for various costume formats.

118c6f0

Todo comment for clarity...

4dd83cf

Fixing tests

80499c9

Deserialize tempo, volume, and video related state.

6c0d257

Add a limit to the number of items a list can have. No-op on 'addToLi…

b436b5f

…st' block if trying to add to a list that is already at the limit.

The stage should always be called 'Stage'.

2dbcdc2

Custom state (e.g. tempo, volume, video related state) should show up…

9892dac

… in a target that has been 'flattened' via JSON.stringify.

Code cleanup and commenting.

4ec25b3

Remove code that was temporarily accomodating for the old version of …

8c1e609

…the default project in gui.

Update test to use new function.

58c9b11

Not providing a zip to deserialize asset functions is not an error.

5d46f8d

List limit should apply to insert block as well.

44b1a2f

Don't really need level 9 compression.

e92db8f

kchadha added the pr - needs review label Apr 6, 2018

kchadha requested review from thisandagain, rschamp and cwillisf April 6, 2018 20:15

thisandagain approved these changes Apr 6, 2018

View reviewed changes

Can't have hyphens in identifiers.

1861b5a

kchadha mentioned this pull request Apr 6, 2018

Import and store video state #1014

Merged

Fix lint error...

9ce6040

kchadha mentioned this pull request Apr 6, 2018

Update default project with new more compact serialization. scratchfoundation/scratch-gui#1738

Merged

thisandagain assigned thisandagain, rschamp and cwillisf Apr 9, 2018

thisandagain added the pr - good to merge label Apr 9, 2018

thisandagain added this to the April 2018 milestone Apr 9, 2018

thisandagain assigned kchadha and unassigned thisandagain, rschamp and cwillisf Apr 9, 2018

thisandagain added pr - needs review and removed pr - good to merge labels Apr 9, 2018

thisandagain assigned thisandagain, cwillisf and rschamp and unassigned kchadha Apr 9, 2018

thisandagain approved these changes Apr 9, 2018

View reviewed changes

rschamp suggested changes Apr 10, 2018

View reviewed changes

kchadha added 2 commits April 10, 2018 15:43

Switch video flipped string back to hyphen.

2f53996

Remove unnecessary comments.

18c1a20

cwillisf mentioned this pull request Apr 10, 2018

Block serialization compression scratchfoundation/scratch-parser#32

Merged

kchadha added 3 commits April 10, 2018 16:53

Adding a bit more clarification to comment.

0df937f

Add one last pass to block serialization to remove orphan primitive s…

585a46f

…hadow blocks.

Ensure we are serializing file extensions for costumes and sounds as …

6f3c84b

…lower case.

cwillisf approved these changes Apr 10, 2018

View reviewed changes

rschamp approved these changes Apr 10, 2018

View reviewed changes

Sounds should still get loaded from storage even if there is not an a…

6c538d0

…udio engine present. This is analagous to costumes getting loaded even if there is no renderer present.

cwillisf approved these changes Apr 11, 2018

View reviewed changes

Pin scratch-parser to an actual version instead of latest.

7fd6dca

kchadha merged commit 8739a52 into scratchfoundation:develop Apr 11, 2018

towerofnix mentioned this pull request May 26, 2018

Remove list limits #1174

Closed

towerofnix mentioned this pull request Jun 9, 2018

Hacked Blocks - Support Argument Hacking #1030

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Block serialization compression #1031

Block serialization compression #1031

kchadha commented Apr 6, 2018 •

edited

Loading

thisandagain left a comment

towerofnix commented Apr 7, 2018

kchadha commented Apr 9, 2018

rschamp left a comment

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

cwillisf left a comment

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

cwillisf left a comment

Honyant commented Mar 22, 2019

kchadha commented Mar 22, 2019

Block serialization compression #1031

Block serialization compression #1031

Conversation

kchadha commented Apr 6, 2018 • edited Loading

Resolves

Proposed Changes

Reason for Changes

Test Coverage

Related PRs

thisandagain left a comment

Choose a reason for hiding this comment

towerofnix commented Apr 7, 2018

kchadha commented Apr 9, 2018

rschamp left a comment

Choose a reason for hiding this comment

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

cwillisf left a comment

Choose a reason for hiding this comment

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

This comment was marked as abuse.

cwillisf left a comment

Choose a reason for hiding this comment

Honyant commented Mar 22, 2019

kchadha commented Mar 22, 2019

kchadha commented Apr 6, 2018 •

edited

Loading