Canvas memory issues and performance

Richard Bair richard.bair at
Tue Jan 8 09:52:31 PST 2013

I suspect a big part of it is performance. Because the FX thread is not the render thread, and because graphics cards want to be used from a single thread, that implies that if we were to write to a "buffered image" then it would be software only algorithms involved. Likewise, taking a series of draw commands to be issued on the graphics card later is likely to use a lot less memory.

On Jan 8, 2013, at 9:46 AM, "Dr. Michael Paus" <mp at> wrote:

> To my opinion this is an absolute must. Not syncing the Canvas when it changes for what ever reason will inevitably end in disaster. Actually I would prefer a Canvas which writes directly into the buffer image without building up a render list first. Not doing this is the reason for all the surprises and the whole discussion we are having here. It would be interesting to know what the reason for this decision was and whether it could be made undone.
> Michael
> Am 08.01.13 18:27, schrieb joe andresen:
>> Given that this is the solution of least surprise, if canvas is allowed
>> to force a sync when it changes then that would work.
>> On 1/8/2013 9:06 AM, Richard Bair wrote:
>>> 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>
>>> 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.
>>>> <>

More information about the openjfx-dev mailing list