Montag, 22. Dezember 2008

Resistance against open standards (almost everywhere)

Disclaimer: This entry is full of half-facts and undirected sweeping swipes against all and everybody ... all this is only my personal opinion.
Furthermore I am I'll and have fever ... take everything with a grain of salt, please.

As you maybe have heard, JavaFX is bundled with ON2 video codecs. No idea who decided why to get this proprietary stuff into JavaFX. Even if ON2 is better than Vorbis - why not give users/developers the choice what to use?
After all, its just another proprietary codec - they could have used Vorbis based stuff without breaking any compatibility as far as I know.
Its like integrating just another binary plug, a plug that cannot be simply replaced by a community developed open-source version due to all the patent stuff. They did this after all the troubles they had with the binary plugs when OpenJDK was opened. Maybe the company behind ON2 decided to somehow pay money or share revenue caused by the success of their codecs boosted by JavaFX. Who knows.
I really like JavaFX, but looking at the video codec decision, I still doubt large companies are able to fully understand OpenSource. It isn't just a magical buzzword to increase your revenue.

Another example is Nokia - everything is well in their open-source universe as long as you don't dig deeper.
The bug with most votes is there since the 770 was released: Adding support for Ogg Vorbis audio playback to the device by default.
The N800 does support all the proprietary stuff like wma, real audio, mp3, aac ... but when MANY users ask for ogg the company is silent.
So what do users of Nokia's internet tablet get? They'll get support for Silverlight, I bet the stuff developed by Novell. Nobody opened a bug-report asking for silverlight support, but many asked for java support in the maemo-mailing lists.
Well, of course Novell's pushing of .NET into Linux doesn't have anything to do with their Microsoft deals.
And some former important developer now anxiously awaits advent of "his" technology conquering the linux world pushing it into Gnome. I doubt he will be celebrated anyway if that succeeds.

There seems to be a huge resistance against open standards, everybody likes squeeze money out of users, by not letting the users decide and forcing them into a format trap. And no, installing a WMA encoder with Windows by default is not choice in my eyes.
I am not against proprietary code, nor am I against large companies. I just would like to have the choice, and choice implies open standards.

By the way ... Merry Christmas :)

Dienstag, 16. Dezember 2008

Almost Pure Java(2D)

The last few days I ported (almost) all the XRender specific C code to Java, and although there are still some bugs left (e.g. it deadlocks from time to time) it works quite well:


All the functionality/features of the C based pipeline have been ported, except text rendering which is a dirty hack for now because I would need some data only available in native data structures by now.
So all the rendering is now done without JNI calls, resulting in ultra-low per-primitive overhead :)

Once all the stuff is working I guess its time for another cleanup ... however without structural changes ;)

Dienstag, 9. Dezember 2008

Java-level protocol generation

The last few days I was experimenting with xcb's new socket-handoff mechanism. It allows mixing self-generated protocol (java2d) with protocol generated by xcb/xlib (all the awt/motif stuff) - with a callback notifying the native side when it should give away control over the socket to the native libraries again.
I had quite a hard time with JNI, not knowing that local object references are only valid during the JNI interaction they were created for - but once that was fixed everything worked out quite fine.

The main advantages are no per-primitive JNI overhead and almost pure java - simplyfing maintainance and better portability as well as better performance.
Of course there are also disadvantages like dependency on a very recent version of libxcb (not in OpenSolaris for now) and maybe a higher protocol generation overhead due to java's managed nature.

For now only rectangles are supported, in the screenshot below the red rect was rendered by the "traditional" Java->C->libX11 call, and all other rects were directly generated in java:


Freitag, 5. Dezember 2008

JXRenderMark

JXRenderMark:
I've released JXRenderMark-0.6, a XRender benchmark written in C which stresses functionality the pipeline depends on. The idea is to be able to show acceleration problems with the benchmark rather than having to build one-time testcases for each incident.

source, binary and results can be found at:
http://78.31.67.79:8080/jxrender/RenderMark.html

Update:
JXRenderMark-0.6 has been integrated into the phoronix benchmark suite :)

NVidia Driver:
NVidia released the second release of the 180.* beta drivers. This release is impressing, especially with the fixes I did last week to the pipeline.
Almost the whole Java2Demo is accelerated, with the only exception of Gradients - all animations just fly :)
A Lightbeam-Nimbus run takes 6200ms, 5200 when I disabled gradient rendering in the pipeline and 4700 with Mask*-Operations and Gradients turned off.
Hopefully Gradients will soon be accalerated, and not only for GF8+ but also GF6/7.

Offscreen pixmaps:
Offscreen-Pixmaps in the X11 pipeline are no more, if you're running on an EXA based driver.
I've written a patch which disables them in the case java is running local and SHMPixmaps are not available, to avoid the 5-10x slowdown linux users were experiencing after distributions defaulted to EXA.
Better no accaleration than some. Will be in JDK6u12 :)