Hi Denis,
Also, I've gotten another 20% improvement out of the design with a few
more tweaks. (Though I measured the 20% in the stripped down version
that I'm prototyping with FX so I'm not sure how much of that 20% would
show up through the layers of the 2D code. Overall, I've about doubled
the frame rates of the prototype since your first drop that you checked
in to the OpenJDK repository.)
How about looking more at the stroking end of the process and I'll dig a
little more into optimal rasterization code. I have a lot of experience
with optimizing rasterizer code (and JNI if it comes to that), but very
little with the curve manipulations involved in stroking (math is so
*hard* at my age ;-)...
...jim
On 11/4/2010 9:20 AM, Clemens Eisserer wrote:
Hi Denis,
It's not obvious to me why this happened, so I think now I will put
this type of optimization aside and convert to JNI,
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.
where profiling
will be easier (for me - I haven't been able to make OProfile work
for java yet).
Have you had a look at the Netbeans profiler? It supports sampling
based testing to keep the influence of the profiler at a minimum.
Thanks for working on this!
- Clemens
