Donnerstag, 22. April 2010

Prebuilt jre-image available

For testing-purposes I've created pre-built jre packages for x86 available at:
http://93.83.133.214/jre-builds/

To try it, simply pass -Dsun.java2d.xrender=True to java, e.g.
> bin/java -Dsun.java2d.xrender=True -jar demo/jfc/Java2D/Java2Demo.jar

Those OpenJDK based builds contain the latest xrender sources, as well as the Jules rasterizer.
I'll try to keep those builds in sync with jdk7 master as far as possible.

Have a lot of fun :)

Kommentare:

cl333r hat gesagt…

Congrats,
I'm wondering why isn't it better to use OpenGL directly?
Afaik XRender exposes only a part of OpenGL and hence it's slower, afaik Cairo tried to use XRender extensively as a back-end but then dropped it for several reasons, otoh recently the Cairo devs decided that going pure OpenGL is better and their preliminary benchmarks have proven that. That's what cairo-gl in version 1.9.6 is about, you can read details about it in their news section.
Am I missing something important why in Java it can't be done? Just wondering..

Linuxhippy hat gesagt…

Really?

Seems I have spent countless hours of development for nothing ;)

cl333r hat gesagt…

I'm just wondering why XRender..

Linuxhippy hat gesagt…

pass -Dsun.java2d.opengl=True to java, and you'll know why.

cl333r hat gesagt…

Well, thanks, I'm actually using this option for like 2 months and while it feels a bit faster it's still nowhere as fast as Java feels on Window$, so I thought the OpenGL back-end is just not optimized and/or doesn't use all of its power to say the least, I thought partly because when this effort has been started Linux had very bad drivers but since then Sun (now Oracle) didn't bother reviewing this OpenGL pipe. But I'm just a Java dev and these are my personal thoughts, you certainly know better hence your comments would be highly appreciated.

Linuxhippy hat gesagt…

Ok, to make it short:

The main argument for XRender is clearly driver support...
The current OpenGL pipeline works only well with the proprietary NVidia driver (sometimes), and is broken almost everywhere else.
XRender is supported on almost every driver+gpu combination and if not there are SSE2 optimized software fallbacks.

> Afaik XRender exposes only a part of
> OpenGL and hence it's slower
Where did you grab that? XRender provides almost everything Java2D needs.

To make it short, XRender is here to stay and it works pretty well.
That is what counts for me.

Andrea Aime hat gesagt…

Hi Clemens,
thanks for sharing a prebuilt JDK and for commenting on the scalability thread on the Sun Java2D forums.

I gave a spin to this build with my little synthentich benchmarks, so far the results are disappointing, the single threaded case shows a performance 4 times slower than Ductus and a very close to the default renderer on your build, but slower than the results I got out of my own build of OpenJDK (b82)

Maybe it's because I'm running a 64bit machine and thus possibly the native libraries are not loaded? I got no error messages though.

Anyways, if you want, I'd like to share the synthetic benchmarks with you.
Contact me at andrea dot aime at gmail dot com to get them

Xerxes Rånby hat gesagt…

Hi, I did some quick benchmarks on using jgears using your prebuilt jre-image

I have fetched the prebuilt jgears.jar from http://trac-hg.assembla.com/jgears/attachment/wiki/WikiStart/jgears.jar?format=raw to be used for benchmarking.

xerxes@xerxes-J464X:openjdk_xrender_20100422/bin/java -Dsun.java2d.xrender=True -jar jgears.jar
XRender pipeline enabled
Jules library successfully loaded
Size: 512x512, 100 frames in 2839 ms = 35,224 FPS
Size: 512x512, 100 frames in 2180 ms = 45,872 FPS
Size: 512x512, 100 frames in 2142 ms = 46,685 FPS

xerxes@xerxes-J464X:openjdk_xrender_20100422/bin/java -jar jgears.jar
Size: 512x512, 100 frames in 4505 ms = 22,198 FPS
Size: 512x512, 100 frames in 3581 ms = 27,925 FPS
Size: 512x512, 100 frames in 3733 ms = 26,788 FPS

xerxes@xerxes-J464X:openjdk_xrender_20100422/bin/java -Dsun.java2d.opengl=True -jar jgears.jar
Could not enable OpenGL pipeline for default config on screen 0
Size: 512x512, 100 frames in 4774 ms = 20,947 FPS
Size: 512x512, 100 frames in 3786 ms = 26,413 FPS
Size: 512x512, 100 frames in 3689 ms = 27,108 FPS

And to sum it up:
I got in average a 1.7X speedincrease using XRender!
Verry cool!

Linuxhippy hat gesagt…

Andrea:
As communicated over mail, Jules was not active because a cmd-line switch was missing.

Using Jules as AATileGenerator was more or less something "for free", so its main-goal was making XRender fast, not providing a fast software-rasterizer.

Althouhg Jules scaled almost linear, and was in many areas a lot faster than Pisces, there are cases where its a lot slower than the closed-source ductus rasterizer.

Hopefully Cairo-1.10 can help here - beeing able to rasterize directly without tesselation.

Xerxes:
Thanks for testing, glad you are happy with the results :)
jgears is more or less a worst-case scenario, excercising all the areas where XRender doesn't really shine compared to software-only-rendering ;)

Xerxes Rånby hat gesagt…

Users reports are extreamly happy using the xrender pipeline when running remotely accessed java gui applications.

http://lists.debian.org/debian-java/2010/05/msg00032.html

"Now, is there a place in /etc where I can set this (-Dsun.java2d.xrender=True) option as a default?"

Cheers
Xerxes

Xerxes Rånby hat gesagt…

Xerxes: You can add

export _JAVA_OPTIONS="-Dsun.java2d.xrender=True"

to your ~/.profile

and it will make all java applications use the xrender pipeline by default!

zstegi hat gesagt…

hi, nice feature and fast!
one question: is there a way to get vsync to work, like with the opengl-pipe? would be nice.

thx, your work is a lifesaver

Linuxhippy hat gesagt…

zstegi: As far as I know, there's no way to control vsync, sorry :/
Would be a nice feature for X in general, make window-resizing etc look smoother.

- Clemens