JavaFX versus AWT/Swing Hardware Acceleration
james.graham at oracle.com
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?
>> 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
More information about the openjfx-dev