On 11/8/2010 6:34 AM, Denis Lila wrote:
Hi Clemens.
I've only followed your discussion with Jim but skipped all the
in-depth discussion.
From my prior experiences usually JNI is not woth the trouble, if
you don't have a serious reason why using native code would have
advantages (like the possibility of using SIMD or when value-types
would be a huge benefit), it has its own performance pitfalls
especially if the workload is small and things like Get*ArrayCritical
cause scalability problems because they have to lock the GC.
Well, Jim Graham said that a native version of the engine still runs
a lot faster than the version with all my changes. That's why I thought
Actually, that report is old. I've now got the new Java version turning
in double the frame rates of the old native version.
it would be a good idea. Also, when not doing antialiasing we usually
feed paths to native consumers, so I thought if pisces used JNI, we
could reduce the java->C transitions five fold. But then I realized that
with antialiasing the opposite would happen, so I'm not sure whether
JNI is a good idea.
That's a good point that the other rasterizers will end up using this
stroking engine and they are native. We can worry about cleaning that
up later. JNI might eventually be a good idea, but lets fix the
algorithm first and then worry about whether it will help this renderer
or if we can make the interface to the other renderers simpler.
...jim
