https://javafx-jira.kenai.com/browse/RT-32242
On Aug 9, 2013, at 8:23 AM, Richard Bair <richard.b...@oracle.com> wrote: >> 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
