2013-03-22 12:35, Laurent Bourgès skrev: > Here is the mail I sent to 2d-dev list. > > ---------- Forwarded message ---------- > From: *Laurent Bourgès* <bourges.laur...@gmail.com > <mailto:bourges.laur...@gmail.com>> > Date: 2013/3/22 > Subject: sun.java2D.pisces big memory usage (waste ?) > To: 2d-dev@openjdk.java.net <mailto:2d-dev@openjdk.java.net> > > > Dear all, > > I recently profiled my swing application (Aspro2: http://www.jmmc.fr/aspro) > using the netbeans profiler (OpenJDK8 / linux x64) and in contrary to Oracle > JDK, it consumes a lot of memory in sun.java2D.pisces code as int[] or > float[] arrays: > - Helpers.widenArray : 25Mb > - Renderer<init>: 75 Mb (from AAShapePipe.draw) > > Here are few profiler screenshots: > http://jmmc.fr/~bourgesl/share/pisces2D/ > <http://jmmc.fr/%7Ebourgesl/share/pisces2D/> > > Aspro2 screenshot illustrating the plot that consumes a lot of memory: > http://jmmc.fr/~bourgesl/share/pisces2D/Capture-Aspro2.png > <http://jmmc.fr/%7Ebourgesl/share/pisces2D/Capture-Aspro2.png> > > My application uses jfreechart that calls graphics2D.draw(shape) where shape > is always a rectangle / line with antialiasing enabled. > > Several questions: > - Why is the antialiasing performed in java code ? I mean is it possible to > use OpenGL or XRender pipelines to perform such tasks ?
I have tested most of the OpenJDK Java2D back-ends in order to find ways to hardware accelerate Java2D on mobile OpenGL ES devices. http://www.raspberrypi.org/phpBB3/viewtopic.php?p=233052#p233052 The default X11 pipeline is not the fastest but it is the most stable open-source implementation and that’s why it is still the default. You can switch to the XRender Java2D pipeline in OpenJDK by passing -Dsun.java2d.xrender=True The XRender backend is developed by Clemens Eisserer and work quite well on hardware with good GPU XRender drivers. Unfortunally this pipeline do not work well on hardware with software CPU fallback when X11 XRender extensions are unavailable. http://linuxhippy.blogspot.se/ - Clemens Eisserer blog. or -Dsun.java2d.opengl=True This is the old OpenGL pipeline that target old fixed function desktop GPU's, note that all recent OpenGL GPU's are designed to be programmed using "shader" based programmable pipelines thus this java2d opengl pipeline is now out-dated and do not work on mobile OpenGL ES hardware. There exist one attempt outside OpenJDK to accelerate Java2D using modern OpenGL calls, this approach renders much faster compared to the closed source Ductus pipeline. http://brandonborkholder.github.com/glg2d/ GLG2D implements a GLG2DCanvas and a GLG2DPanel that you can use to wrap existing JComponents in order to get the components rendered using hardware acceleration. Example: https://gist.github.com/brandonborkholder/3909397 > - Is there some docs explaining the java2D code and the different > implementations (openjdk, oracle, xrender, opengl ...) ? > - how could I help improving that code (Renderer ...) to avoid so many array > allocations / resizing (array sizing or using a thread context object to > reuse allocated int[] / float[] arrays) ? > > Does somebody work on that topic ? has some ideas to optimize that code > (pisces) ? > > Regards, > Laurent > Like you discovered most of the Java2D back-ends still make quite heavy use of the software fall-back in sun.java2d.loops.* . On mobile OpenGL ES hardware none of the above pipelines are currently able to make use of the GPU thus Java2D do have a problem to scale and operate fast on mobile devices and the latest OpenGL GPU drivers. The GLG2D implementation is almost OpenGL ES 2 ready but it require replacing some OpenGL 2 desktop specific code with OpenGL ES 2 compatible code. Cheers Xerxes
