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 :)
Abonnieren
Kommentare zum Post (Atom)
Kommentare:
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..
Really?
Seems I have spent countless hours of development for nothing ;)
I'm just wondering why XRender..
pass -Dsun.java2d.opengl=True to java, and you'll know why.
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.
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.
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
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!
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 ;)
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: 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!
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
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
Kommentar veröffentlichen