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 coverage).

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...

                        ...jim

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:
https://weblogs.java.net/blog/opinali/archive/2010/05/03/first-long-look-javafx-13-and-prism

  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

Reply via email to