Rendering in JavaFX

Question

Hi,
I am currently working on my bachelor thesis about JavaFX 2
I have a few questions about rendering in JavaFX
I don’t really understand what the glass toolkit is for and how it’s connected to prism.
If the glass toolkit is firing the pulse event how does prism know that it has to render a frame?
And how does the Quantum Toolkit handling the threads?
And what is the advantage of having two threads (Application and Prism Render Thread) instead of one like in Swing?
I haven’t found much about rendering in the documentation so please help me. :)

Answer 1

Hi David,
Glass is to FX as AWT is to JavaSE. Sort of :-). Glass is our windowing toolkit implementation. It is responsible for showing windows (including Stage, Popup, etc), managing the event queue, passing events up to JavaFX, and setting up timers. Every native application (on Windows, Mac, Linux, etc) has a native event queue. On some platforms like Mac, you get callbacks called whenever an event needs to be handled (that is, the native system pumps the event queue and delivers events to native callback methods). So on Mac Glass, we get these native callbacks, turn them in to JavaFX events, and send them to JavaFX (more or less). On Windows we have to manually pump the event queue, pulling off the event, creating the JavaFX event equivalent, and then pass that up to JavaFX for dispatching.
Pulse events are normal events on our event queue, but they are generated based on a timer. Glass sets up a timer which fires off every 16.666ms. It is either based on just a hi resolution system timer (native), or it is based on a callback from the OS whenever the video card refresh occurs. This latter mechanism is much more precise, system timers can sometimes drift leading to "jitter" in animations whereas the video card refresh is pretty rock solid. When JavaFX gets notified by glass when the timer fires, it checks to see: is there a pulse already queued up or being handled? If so, don't fire another pulse (keeps us from flooding the event queue with pulses). If the scene is not dirty and there are no animations, then we don't need to handle the pulse. Otherwise if the scene is clean but there are animations, then we handle the pulse. A PulseEvent is then created and put on the event queue.
During the normal process of handling the events on the event queue, when we encounter a pulse event, we then do the following things:
- Process animations
- Process CSS
- Process Layout
- Synchronize from the FX scene graph to the render tree (Prism)
- Pick the scene and update the mouse hover state if a node has moved under the cursor or moved out from under the cursor
The render thread then goes off and renders after the synchronization step has occurred.
Quantum is the thing that listens to Glass pulse timer events and creates the PulseEvent and adds it to the event queue, and is also the thing that handles the pulse event, causing animations to be processed and then telling each scene to handle the pulse event (where each scene processes CSS, layout, and synchronizes etc). Quantum then tells the render thread to go off and render.
Presently in JavaFX, although we have a render thread and application thread, they both essentially run synchronous. I have a patch going into 3.0 as soon as the repo opens that allows us to run multithreaded, where the FX app thread and render thread will be running in parallel except for the brief period of time where they synchronize during the pulse. We have seen 1.5x - 2x performance improvement on tablets by running these threads in parallel. We've also noticed 40%+ performance improvement on desktop in some of the scenarios I've run thus far. Having multiple threads just makes sense in a world where we have multiple cores (even on embedded systems!). Even on a single core, multiple threads might still be advantageous because the CPU doesn't have to wait on memory read operations or GPU operations but can be busy computing the state for the next rendered frame. Having multiple threads does increase the memory overhead, but actually it may not do so very significantly (we have one prototype where we found that the performance cost in constantly converting from FX Color to native Color objects was so bad that caching the converted color object was cheaper anyway, so it isn't clear that even in an immediate-mode style single-threaded rendering system that you'd save much in terms of memory).
I don't know when your thesis is due by, unfortunately a lot of code in this area hasn't been open sourced yet so you're kind of flying blind. May the decompiler ever guide you ;-)