Canvas memory issues and performance
joseph.andresen at oracle.com
Mon Jan 7 15:09:34 PST 2013
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).
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...
More information about the openjfx-dev