Add methods for modifying Graphics instructions

It would be handy to have public APIs on Graphics to modify the Graphics instructions queue.

For example, when you clone a Shape, the instructions queue can be shared or cloned (using the recursive argument), however even when cloned, it will still share references to existing commands. This means if you save a command on a shape, and clone it, modifying the saved command affects both shapes:

var shape = new createjs.Shape();
var rectCommand = shape.graphics.beginFill("red").drawRect(0,0,100,100).command;

var shape2 = shape.clone(true);

rectCommand.w = 200; // Modify the width of the shape

I would expect this to just modify the first, but since the clone does not deep-copy the instructions, the command is shared between shapes.

Ideally, the recursive flag actually clones the instructions, but if not, an API could provide easy access to modify the instructions:

var rect2 = rectCommand.clone(); // Would be nice

var rect2 = new createjs.Graphics.Rect(0,0,200,200);
shape2.graphics.replace(rectCommand, rect2);

// OR

var index = shape2.graphics.indexOf(rectCommand);
shape2.graphics.splice(index, 1, [rect2]);

Totally open to implementation. Just some ideas.

[lannymcnie]

How would that work if you added the same command multiple times?

[gskinner]

There are two issues with adding arbitrary access to the command list:

1. There is a bunch of logic around when to inject / reset fills and stroke properties. This logic would break with arbitrary access.

2. We have plans to support bounds for Shape. This involves calculating the points in a Graphic object that comprise the convex hull. This is somewhat expensive to do. By only appending to the command list, we can retain the significan point list and only calculate against newly added points on-demand. This will also break if you edit existing commands, but that API is currently very constrained, and makes documenting how to address this simpler.

With that said, deep cloning is a separate ask, and something that I could see us adding. It’s mostly a balance of library file size versus functionality. If deep cloning is something people think will provide significant benefit, then someone should open a separate issue for it (referencing this one), and we can evaluate it there.

Closing this, but feel free to comment further if you have questions or feedback.