Canvas memory issues and performance

[Richard Bair]

Why can't we cause a change in the canvas to require another pulse? We probably have code right now which short-circuits any pulse for a window that isn't visible, but in the case of a canvas being dirty we could un-circumvent that I'm sure. Is there a reason why the rendering code would die in such a case?

Richard

On Jan 7, 2013, at 3:09 PM, joe andresen <joseph.andresen at oracle.com> wrote:

> On 1/7/2013 2:14 PM, Richard Bair wrote:
>>>> Canvas is different then the other nodes in the scene graph in the sense that it could, not 100% of the time but sometimes, want to be processed when not visible, but generally when a node is not visible you do not want to process(render) it.
>>> I understand, but it is also not like other nodes in the sense that if it does not process it queues commands indefinitely and you can run out of memory.  Which is worse? Processing when not visible, or running out of memory?  At some point the producer must block and let the consumer catch up.  Leaving the Canvas command queue unbounded is a disaster waiting to happen... I know, it already happened to me :-)
>> This has been my feeling too. I don't like the fact that by default the Canvas will cause your app to explode when the user minimizes your application. I don't remember what the problem was, Joe / Jim can you refresh us on what the core problem here is?
> The problem lies in the persistent nature of canvas requiring the processing of every command a user submits. Also, the buffer of commands is consumed only during the sync of the two threads. Now enter a time when the thread syncing is stopped, the user can continue to issue draw calls to the canvas and stack the buffer. Do this with a displacement map effect, and you will run out of heap in seconds.
> 
> This was discovered at the same time as the context loss problem we had with D3D, and there wasn't enough time to fix both issues for 2.2.
> 
> It is also difficult to know every time when the threads will not sync. There are events to detect some cases, like window locking and minimizing, but I am not sure if we can identify all of them.
> 
> sigh, and i was going to attach a program to show this behavior but it seems we have introduced a regression with 8.0 multithreading. If you run the attached program on 2.2 it should repaint the rectangles that would have been painted while the threads were not syncing. (a simple ctrl-alt-delete in windows, lock, and return would do).
> 
> -J
> 
> PS. We (the graphics team) have some ideas of fixing this and I hinted at some of them earlier.
> 
> 
> 
> <TestCanvas.java>