Canvas memory issues and performance

[joe andresen]

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.



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestCanvas.java
Url: http://mail.openjdk.java.net/pipermail/openjfx-dev/attachments/20130107/c16f908b/TestCanvas.java