Canvas blowing up (was Re: JavaFX Media issues)

[steve.x.northover at oracle.com]

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
>