Hi Jim. > 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.)
Can I see your new version? > 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 ;-)... Sounds good. Have you implemented your idea of processing one pixel row at a time, as opposed to processing subpixel rows? If not, I could do that. Thanks, Denis. ----- "Jim Graham" <james.gra...@oracle.com> wrote: > Hi Denis, > > ...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
