API Review RT:17407 Canvas Node

[Jim Graham]

Keep in mind, though, that the buffer is essentially a modification of 
the original Canvas node.  Everything you write to it must be single 
threaded with the same constraints as changing its other node 
attributes.  If we want to write to it from an arbitrary thread then 
we'd need to be able to create independent GC objects and have a flush() 
in them - and, unlike AWT where flush() just asks for pending operations 
to happen immediately rather than asynchronously, this flush() would be 
mandatory and would have to synchronize with the scene graph 
modification thread...

			...jim

On 4/25/12 1:16 PM, Kevin Rushforth wrote:
> Right, the "drawing" commands just write into an internal buffer. The
> buffer is synced to Prism along with any scene graph changes, and the
> actual rendering happens on the rendering thread along with any other
> rendering. Given this, I wouldn't expect the UI thread to be blocked for
> any appreciable length of time just filling up the buffer.
>
> If it does become a problem, we could probably extend the API to support
> creating a GC and then setting it on the Canvas as you suggest. Or do
> you think that is required for the first version?
>
> -- Kevin
>
>
> Richard Bair wrote:
>> Why can't I draw on a background thread? Don't we internally setup a buffer of draw commands, and then sync those across during the pulse synchronization? If so, can't we let people draw on a background thread (maybe to a created GC?) and then set that on the Canvas in one shot on the FX thread?
>>
>> This does seem like a pretty compelling use case. Especially since we won't be handling dirty regions for anybody, they might have a fair amount to draw.
>>
>> Richard
>>
>> On Apr 25, 2012, at 11:23 AM, Jim Graham wrote:
>>
>>
>>> Right now when you draw it has to be on the thread on which you respond to inputs or do other SG modifications.  In other words, any thread where you can appropriately call cv.setWidth(), group.add(cv), etc. is a thread you can render on.  The rendering is "remembered" in a buffer and it isn't actually drawn until the render pass.  At that point we simply eat the buffer and render it in a tight loop so any pauses for thought in your rendering code would only affect the event and SG modification threads, not the render thread.  (The pauses aren't stored in the buffer. ;)
>>>
>>> We looked at ways of relaxing that further, but they won't come in this first round of the API.  It would necessitate having multiple HW contexts and have a context set aside to only be used for Canvas rendering into its texture with a clearly defined buffer swap that has to be synchronized across the threads.  Unfortunately that model is not easy to support with D3D, our most common hw solution, so it is still just a pet theory...
>>>
>>> 			...jim
>>>
>>> On 4/25/12 1:38 AM, Dr. Michael Paus wrote:
>>>
>>>> Am 25.04.2012 10:03, schrieb Jim Graham:
>>>>
>>>>> Hmmm... More variants of Canvas or more attributes to set...?
>>>>>
>>>>>
>>>> I was just thinking about potential use-cases for the canvas node and
>>>> stumbled over the
>>>> following question. How can I still provide a super-smooth GUI if I have
>>>> a canvas drawing
>>>> which lasts longer than the interval between two pulses. Maybe it even
>>>> lasts more than
>>>> a second. My understanding of the current canvas design proposal is that
>>>> when I redraw
>>>> the canvas, for whatever reason, the GUI is basically blocked for this
>>>> time. Is that true?
>>>>
>>>> If the above interpretation is right I would like to propose a
>>>> modification of the design
>>>> which makes it possible to have a double buffer canvas where the
>>>> currently active
>>>> buffer is redrawn whenever the JavaFX runtime needs to redraw the node
>>>> and where
>>>> I can render into the second buffer from ANY thread at any time without
>>>> disturbing the
>>>> smoothness of the GUI. When I am done with the rendering I just signal a
>>>> buffer switch
>>>> and with the next pulse the new buffer is shown.
>>>>
>>>> What do you think?
>>>>
>>>> Michael
>>>>
>>>>
>>
>>