> I mean, it looks like it is working for a few seconds,
> but then as the memory fills with the Canvas backlog it can lead to the GC
> using a lot more CPU, thus reducing the ability for Canvas to process its
> command queue even further, well it just collapses in on itself  and dies.

Forking the thread.

The problem with Canvas is that 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.

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. 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 your specific media use case this isn't as important.

Richard

Reply via email to