JavaFX versus AWT/Swing Hardware Acceleration

Jim Graham james.graham at
Fri Jan 3 16:24:47 PST 2014

Some key points hidden in the shadows here...

We have direct rendering shaders for simple objects like rects, ovals, 
roundrects, simple single lines.  We can handle simple strokes on those 
with only the stroke width being customized (must use an expected join, 
cap, no dashing).

Text is done with a grayscale bitmap cache.  We also have LCD glyph 
caches as well on the GPU.  I'd have to check to see how much we cache 
stroked text vs. using a default shape fill.

These shaders can deal with most fills, except if you have too many 
colors in your gradients then we have to manually compute the colors, 
but I believe we still use a shader to merge the colors with the 
coverage and get the result on to the screen (I can dig in the code and 
check if it matters - I think the max colors are like 16).

Besides those, we render other things like Polygons, Polylines, Path, 
SVGPath using a native version of Pisces and caching the masks on the 
GPU.  The masks will be invalidated when the path changes in any way, 
and for any transform change other than a translate (I believe).  This 
is done as a grayscale texture and is separate from the kind of caching 
done when you select a Node's cache hint (that hint will result in a 
full-color cache that will be rendered with a simple blit operation and 
can cache effects and other node attributes in addition to just shape 

On the table is for someone to create a mechanism similar to the NV_PATH 
rendering extension that lets us feed the path to the GPU and use 
stencils to render it at hardware speeds.  Unfortunately, the nVidia 
extension requires an nVidia GPU and only works on OpenGL, but I believe 
that much of that is due to them accelerating path stroking on the GPU. 
  We could probably at least use similar techniques to their extension 
to do fills and rely on our existing code to convert strokes to fill 
paths to couple with it.  Their techniques require certain stencil modes 
that are not universal so some investigation needs to be done to see how 
widely any of these techniques could be supported on either/both of D3D 
and OGL (and embedded).

Did you want a comparison to Java2D or were you more interested in just 
what FX can do?  I'd have to do some digging to figure out what parts of 
this aren't handled in J2D...


On 1/3/14 9:24 AM, Kevin Rushforth wrote:
> A couple other thoughts.
> 1) JavaFX doesn't use software loops for the actual rendering as long as
> the card is capable of supporting Prism. We do mix HW and SW in that we
> generate masks from a path in SW, but we cache that on the card and
> render it using shaders.
> 2) JavaFX can support Intel HD on Windows (something in the way Java2D
> uses D3D exposes a bug in Intel's driver so it is disabled).
> Jim can probably come up with more.
> -- Kevin
> Stephen F Northover wrote:
>> Hi Ryan,
>> I'll let others describe hardware acceleration in AWT/Swing but in
>> JavaFX, D3D and ES2 shaders are used to draw.  These run directly on
>> the graphics card and render data that is downloaded there.  Because
>> JavaFX has a scene graph, it has a notion of what has been changed and
>> can render only a subset of the scene graph nodes.
>> This is a very high level description of JavaFX but captures the
>> essence of what is happening.  Any other FX committers want to comment?
>> Steve
>> On 2014-01-01 1:39 PM, Ryan Cuprak wrote:
>>>   What is the difference between hardware acceleration in JavaFX
>>> versus Swing/AWT? I heard a while back someone claim that Swing/AWT
>>> could never fully leverage hardware acceleration. However there are
>>> the usual mix of -D parameters (sun.java2.opengl/sun.java2d.d3d,
>>> etc.) for Swing/AWT. So I am just wondering how JavaFX’s acceleration
>>> differs from the hardware acceleration in Swing. When I was giving a
>>> talk at a JUG meeting someone called me out on the hardware
>>> acceleration bit and I realized I didn’t fully understand the
>>> differences between the two.
>>>   I understand that JavaFX has a scene graph and Swing doesn’t etc.
>>> So I am assuming that the scene graph operations are optimized on the
>>> GPU whereas if you were trying to replicate a scene graph in Swing
>>> you would obviously be doing all the work on the CPU. So Swing’s
>>> hardware acceleration is more about buffers?
>>>   I did come across this article:
>>>   Specifically this line caught my attention "Prism finally renders
>>> effects with full hardware acceleration and without the extra buffer
>>> copies that spoil effects on the Swing toolkit.”
>>>   This article is a dated - brings up a second question about
>>> hardware acceleration with a hybrid Swing/JavaFX application - what
>>> happens?
>>>     Thanks,
>>> -Ryan

More information about the openjfx-dev mailing list