JavaFX versus AWT/Swing Hardware Acceleration

[Jim Graham]

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

			...jim