JavaFX versus AWT/Swing Hardware Acceleration
james.graham at oracle.com
Fri Jan 3 16:32:18 PST 2014
Chien answered some of these, but here are my answers (inline)...
On 1/3/14 9:40 AM, Steve Hannah wrote:
>> 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.
> Can you describe roughly how the caching works? I understand that the
> alpha mask is stored in OGL as a texture, but there are an infinite number
> of possible paths to be masked. How many textures can be stored at once (on
> say an iPhone)? I'm guessing JavaFX uses some sort of LRU caching
> algorithm for these textures?
As Chien mentioned, Lombard/JDK8 has a new texture management component
that lets us purge textures as needed on a LRU basis. The caching tends
to simply just validate the cached mask on every Shape node that has a
cached mask on every frame and it sometimes finds that the texture needs
to be recreated if we are running low. Worst case, the cached texture
needs to be recreated on every frame.
> I ask this because I've been playing around directly with the Pisces C
> library directly to generate alpha masks and render them using shaders. I
> can see a performance increase of 4x in using alpha masks rather than full
> argb pixels (due to 1 byte per pixel instead of 4), but I'm curious about
> other savings that JavaFX makes with this method.
Are you referring to the C version of Pisces in the FX sources?
Actually, there are 2 currently in the FX source base. There is one
version (which has both a Java and native port) of the Pisces renderer
that historically came from OpenJDK which got its version from an
embedded port of Java that didn't use Ductus. It is used by the D3D and
OGL pipelines. The second version came in when the SW pipeline was
added recently, it went back to the original source base that had Pisces
integrated with a full set of rendering loops and it brought that whole
package in to be a complete rendering solution. So there may be some
divergence between the two versions of the rasterizer given the
circuitous history of how the version used by D3D/OGL got into the FX
source base and the fact that there was some work done on both versions
since they diverged back in the OpenJDK early days.
I'd be curious to see your work and how it might help us to have some
tighter integration between the rasterizers and the OGL/D3D shaders...
More information about the openjfx-dev