[OpenJDK 2D-Dev] [OpenJDK Rasterizer] Fwd: sun.java2D.pisces big memory usage (waste ?)
xerxes at zafena.se
Mon Mar 25 11:06:38 UTC 2013
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.laurent at gmail.com <mailto:bourges.laurent at gmail.com>>
> Date: 2013/3/22
> Subject: sun.java2D.pisces big memory usage (waste ?)
> To: 2d-dev at openjdk.java.net <mailto:2d-dev at 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.
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
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.
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.
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.
> - 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) ?
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.
More information about the 2d-dev