You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SVG renderer functionality should be exported in a granular way, so each place that depends on it can take only what it needs (e.g. 2.0 -> 3.0 SVG conversion, measuring SVGs, deserializing SVGs, actually drawing SVGs). This is blocking scratchfoundation/scratch-render#594.
Actual Behavior
Currently there's lots of functionality mixed into SvgRenderer, some of which is used in scratch-render, some of which is used in scratch-vm, etc. This should all be separated out, especially since #127 will be adding lots of scratch-render-specific SVG rendering code, and it would be cleaner for that to be able to live in scratch-render.
The text was updated successfully, but these errors were encountered:
This looks like a really good improvement! It could also be a really helpful step towards some of our other SVG issues. I'm going to talk to our tech lead about it to make sure it's ok, and then we'll start looking at putting this in.
Expected Behavior
SVG renderer functionality should be exported in a granular way, so each place that depends on it can take only what it needs (e.g. 2.0 -> 3.0 SVG conversion, measuring SVGs, deserializing SVGs, actually drawing SVGs). This is blocking scratchfoundation/scratch-render#594.
Actual Behavior
Currently there's lots of functionality mixed into
SvgRenderer
, some of which is used inscratch-render
, some of which is used inscratch-vm
, etc. This should all be separated out, especially since #127 will be adding lots ofscratch-render
-specific SVG rendering code, and it would be cleaner for that to be able to live inscratch-render
.The text was updated successfully, but these errors were encountered: