2012-03-20 21:10, Matthias Klose skrev:
> On 20.03.2012 13:48, Barry Hawkins wrote:
>> On 3/20/12 7:41 AM, Andrew Haley wrote:
>>> On 03/19/2012 07:11 PM, Barry Hawkins wrote:
>>>> The focus of my message was to point out the need for users of Debian and
>>>> its derivatives to be able to install an official JRE or JDK from Oracle.
>>>> If I gave the impression of criticizing OpenJDK, my apologies; that was
>>>> not the intent.
>>>>
>>>> Like so many others, I'll be happy when OpenJDK is the de facto choice for
>>>> all things based on the JVM. Currently, high performance and graphical
>>>> applications still see significant improvement when using the Oracle
>>>> JRE/JDK.
>>>
>>> Actual specific problems with performance are something we can address.
>>> Core performance differences are very few: It's the same VM. Oracle does
>>> have a few magic optimized classes we don't have, and they have a
>>> proprietary font renderer. We don't use Oracle's plugin. There isn't much
>>> else.
>
> CCing Xerxes here. He did point out that turning on another renderer does
> improve performance in some cases.
OpenJDK currently contains 4+ different Java2D renderers, of course only one
are enabled by default.
I will summary the current OpenJDK Java2D situation:
The well tested ones:
0. The Oracle JavaSE contains the Ductus Java2D renderer this part have not
been open sourced by Oracle. So we cant use it, this part got replaced in
OpenJDK by "pisces" from phoneme.
1. In OpenJDK we the Pisces Java2d rasterizer enabled by default, it work but
its kind of slow and revert to software rendered fall-back for most operations,
unfortunately.
http://openjdk.java.net/groups/2d/
The well tested but found not to be working one:
2. The OpenGL backend, java -Dsun.java2d.xrender=True
This back-end have been included all the time into OpenJDK and also found
in the Oracle JavaSE builds,
It work on GNU/Linux desktop OpenGL hardware.
The main reason why it never got enabled by default are the poor support
for the buggy/fixed-pipeline OpenGL GPU drivers.
The new kids:
3a. The Xrender backend created by, Clemens Eisserer, can be enabled at runtime
by passing java -Dsun.java2d.xrender=True
(Use True for verbose output and true for non-verbose output)
This backend makes use of the Xrender GPU driver support that are actually
quite good on Linux systems, For networked X11 applications this back-end
really flies!
Since this back-end have been merged you can simply switch it on at runtime
to test its performance.
http://openjdk.java.net/projects/xrender/
3b. The Xrender back-end + jules This part combines the Xrender back-end with a
tweaked Cairo rasterizer, Clemens never had time to clean up the Cairo patches
so this variant only exist as a secret addon
by using the Xrender backend and dropping in the libjules into the JRE.
http://linuxhippy.blogspot.se/2009/11/jules-cairo-binding-001-release.html
The future:
4. The pluggable Caciocavallo back-end, created by Mario Torre and Roman
Kenkke, Cacio are a portability layer that is well integrated into OpenJDK and
enables Java2D on new platforms,
the only thing missing in OpenJDK are the new compiled plug-in "peers".
http://openjdk.java.net/projects/caciocavallo/
By compiling a peer you can get Java2D running on many new interesting
combinations like this Cacao-web HTML5 backend.
http://linuxhippy.blogspot.se/2011/07/prebuilt-demo-release-available.html
5. The JogAmp JOGL GLG2D back-end, this new backend under development make use
of the well tested JogAmp JOGL 2.0 library to render hardware accelerated using
the latest OpenGL 2 GPU drivers.
Since JogAmp know how to workaround the many bugs in the OpenGL drivers
this back-end can become a fast, up to 10x improvement, and stable for all
Java2D use.
http://brandonborkholder.github.com/glg2d/
Without a testing framework its hard to know when the new back-ends 3a.-5. are
stable and ready to replace the slow 1. Pisces Java2D rasterizer in OpenJDK.
Cheers
Xerxes
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f744189.7050...@zafena.se
