If you have a canvas and you scribble on it, and then scribble on it some more, and then scribble on it some more, then in order for us to get the right result in the end, we need to replay all those scribbles in order. If pulses are not happening, we still need to remember these scribbles so we can draw the right result. The problem is that this can lead to OOM errors (see RT-23312).

BUT, if you issue a command to the canvas which will cause it to "clear" all its contents, then we could throw away any previously buffered data. Right now the only way to do that would be a fillRect with a solid fill where the fillRect encompasses the entire canvas area, or a clearRect where the clearRect encompasses the entire canvas area.

This seems like a very simple fix. GraphicsContext.clearRect and GraphicsContext.fillRect should both (under the right conditions) throw away the previously buffered commands. Then all you have to do is be sure to make one of these calls (likely just a clearRect) before each frame, and we'll never buffer more than a single frame's worth of data. We could also add a "clear" method which is "clearRect(0, 0, w, h)" to make this more foolproof, and then document it as a best practice to clear the canvas before each rendering if you intend to redraw the entire thing on each frame.

If you're making use of manually operated "dirty rects" so that you only clear the damaged area to repaint, then we couldn't employ this technique and we'd have to buffer 'till kingdom come (or cause a pulse / render step in cases where we wouldn't have otherwise). So we still need a mechanism exposed in the scene graph of "liveness" and associated events so that when the scene is no longer live (for example, when minimized) you could stop your animation timer, but for the specific use case of John Hendrikx and others where they are using canvas to draw pixels from VLC, this would work quite well and is a decent optimization on our part anyway.