This was already being used for sb3s and sprite3s, but the code was repeated in different places. Make a single helper that downloads blobs, and make all download paths use it.
Override the z-index for the blocks drag layer. At 1000, it will be over everything in the gui other than the navbar itself (monitors on the stage, tutorials, alerts, dropdown menus, etc.)
This fixes a problem where having a non-default locale set during the initial load would display the blocks in the default toolbox in the wrong language, because the toolbox recycling toggle in setLocale does not work on initial load because there is no editing target to refresh.
Since the common use-case is download/edit/re-upload, and we do not want to explode the storage size of assets (which are considerably larger with fonts inlined), just do what scratch2 did and do not inline the fonts. This is not ideal if kids want to use the costumes for other purposes, but until we can create a way to strip inlined fonts before uploading to the asset server, this is the conservative way to go.
This fixes the issue where you could not see any new variables or custom block callers, as well as fixing the issue where the toolbox did not update from then on.
Need to store the rendered xml because the props can change while the blocks tab is hidden, but we re-render based on what was rendered, not the previous props (which may not have been rendered).
This is similar to the `ThrottledPropertyHOC` in that there may be prop changes that do not get rendered, but in this case for a different reason.
This increases the performance of switching between code and other editor tabs, as well as improving the "See Inside" performance. It makes switching to the code tab as fast as switching between sprites.
The fontInliner from the scratch-svg-renderer was changed recently to work entirely on strings, so we can use that instead of parsing/loading/possibly drawing/stringifying the entire SVG.
This does not address the size-1 cache issue where the cache is invalidated any time there is more than 1 sprite. But that can be handled later.
Using the 4x CPU slowdown in chrome dev tools, on a simple costume that just has a single text element the getCostumeUrl time goes from 10ms to 1ms, very important for updating in a timely way.
Paul Kaplan