Internal scene graph redraw handling
james.graham at oracle.com
Tue Sep 8 23:23:15 UTC 2015
I assume by "canvas" you mean "a Canvas Node"? I can only answer one of
On 9/8/15 11:14 AM, Dr. Michael Paus wrote:
> When an update of the canvas is in progress will this delay the next
> pulse until all
> internal drawing within the canvas is finished? From my observations I
> think so.
All calls to the GraphicsContext of a Canvas will be executed on the
next rendering pass. The GraphicsContext methods place their information
in a command buffer and that command buffer is handed off to the
rendering thread the next time the Nodes are synchronized with the
rendering thread's view of the scene graph. At that time the rendering
thread will fully render all commands in a Canvas node's queue before it
renders that Canvas node to the scene. We don't have any support for
"render for only X ms" in the Canvas rendering so you'd have to break it
Also, as of one of the recent 8u releases, even nodes that are not
visible will be fully rendered on every rendering pass to avoid their
command queues growing uncontrollably if they scroll off the screen.
This is only true of Canvas nodes that are part of a scene that is being
rendered, though - an orphan canvas will just keep accumulating a
command queue and it won't be rendered until it is part of an active scene.
As such, the Canvas rendering commands don't "delay" the next pulse so
much as they make the next rendering pass take longer to do its work.
I have no further information to add about your questions about how to
use runLater to break up the rendering - someone else will have to chime
in on that, but in theory if you can break up your calls to
GraphicsContext over multiple rendering pulses then yes, you can
minimize the delay caused by having to flush all of the rendering calls...
More information about the openjfx-dev