[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Fwd: sun.java2D.pisces big memory usage (waste ?)
From:       <xerxes () zafena ! se>
Date:       2013-03-25 11:06:38
Message-ID: 51502FBE.6060008 () zafena ! se
[Download RAW message or body]

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@gmail.com \
>                 <mailto:bourges.laurent@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


[prev in list] [next in list] [prev in thread] [next in thread]