We would still do the fill but we could throw away any buffered commands
that happened before the fill.
Steve
On 09/08/2013 12:16 PM, Dr. Michael Paus wrote:
What would be the performance penalty for using this quick-fix? The
clear/fill commands do not
just clear the command buffer. They also fill the canvas area with a
certain color. So in normal
operation the canvas is always filled twice for each frame, isn't it?
Am 09.08.13 17:23, schrieb Richard Bair:
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
