Submitted by The WebP image format based on VP8 and released by Google recently now has a native Java decoder. The new decoder can be run in any browser with Java enabled and could help provide a solution for user otherwise unable to view WebP content. A demo applet of the decoder in action is also available.
Sorry for being a grammer nazy, but their is no such thing as native when talking about Java*. I mean Java isn’t native on any platform. 😉
It’s all extra layers. You could say, a pure Java WebP decoder. That would make more sense.
* OK, their is JNI, but that is using native libraries from within Java
not if you think of java(JVM) as the platform
No, its native to Java. Native and foreign are relative qualifiers.
I’ll never forget this guy I met ( recent emigrant from another country to the us), who used to rail against all of the “foreigners” here, including a co-worker that was Cherokee. It would have been funnier, if he had not been so racist.
Why not C? Most system level software and many libraries are in C.
WebP is based from VP8 and VP8 is from Google.
From what I could gather Google is none too keen on C.
Calls it “unnecessary complicated” and is the reason it is developing Go.
I myself don’t know anything about C++ and can’t give an informed opinion on the legitimacy of Google’s claims except from posts I read about C.
The gist of it is as I have it is that C++ is difficult to master but very robust.
Maybe other comments can enlighten us.
Yet they developed Google Chrome in…C++…
Webkit was already C++ and there really is not a good alternative high performance language which works on all platforms since Objective-C is restricted to Apple platforms in practice, D is not ready (nor might ever be) and Java is, well, just plain awful for building client side applications. Go is just a toy language at the moment.
Well it depends what you mean by client side. If you mean GUI’s then this is a language agnostic thing. What really makes the difference here is the GUI toolkits (Qt being a particularly good one – which is available for both C++ and Java indirectly).
In terms of languages itself, C++ has inconsistent, ugly and very powerful syntax. Java is much more enjoyable to program in, allbeit slightly less powerful (pointers, memory access etc). Generally I agree with your point except about Java
C++ is good enough and very widespread. There is simply no alternative that is that much better. For embedded C++ is the obvious choice due to its low-level capabilities. For very complex higher-level stuff, Java is a better choice.
P.S. I program daily in C/C++ for embedded things.
Edited 2010-11-16 08:39 UTC
I develop in Qt and C++ daily. I agree that the C++ language syntax is ugly, but this is for a large part to to its C backwards compatibility. D is nicer, but we’ll have to live with C++ and it’s quirks for now.
Ok, maybe I should have explained myself a bit here. I personally do not like the Swing toolkit and think it looks ugly on every platform. It is lacking in functionality present in other toolkits such as Qt and it’s responsiveness is also not great. It also seems to be pretty much abandoned.
QtJambi has been abandoned by Nokia, so that is not really an option anymore.
In terms of languages itself, Java is a pain to program in when you are dealing with things like codecs due to the lack of unsigned datatypes, which is still an incredibly stupid decision. Also there is no way to access the SIMD units of modern CPUs. So any codec written in Pure Java, as Sun liked to call it, is slow as hell compared to the optimized C version. So mostly you are stuck using external C libraries and bind them with JNI. Then of course the fun starts with the Java memory model. Anyway, I would never recommend Java to be used outside the server environment.
Fair points. I also do not like Swing (SWT is better)!
The original Webp decoder is in c (and some assembly iirc), I don’t think this java decoder has anything to do with Google apart from it decoding Google’s WebP format.
Because there already is a library written in C called libvpx – the same library used for VP8 encoding and decoding.
For one simple reason…. There are many better languages than C! 😉
Edited 2010-11-15 15:07 UTC
Sun never cared about it and neither does Oracle.
So you encode your pictures differently to save a new bytes of traffic but you’re now serving a Java applet.
Also, its slow as hell to start up a vm in a web browser. Thats why Java applets, Java web start, and JavaFx never took off.
It’s actually gotten a lot better on Windows in recent years. On Mac it is still kinda slow to start up. I totally agree though that embedding a Java applet in order to show an image in a different format is the definition of counter-intuitive….
If WebP is just a fourcc, a data chunk length, and the data… isn’t that a few lines of code in any language?
And then it feeds the data to the VP8 decoder!
It boggles my mind that this is news.
Right, all the hard work is writing the Java VP8 decoder. It’s all part of the same project.
if a computer is just a bunch of wire and transistor anyway, isn’t that a few number of switch in different form ?
And then it need the switch to be faster!
I boggles my mind that you are unimpressed.
Reading the link, the point was never to create a WebP decoder in java. They’re trying to port libvpx, and are using WebP as a testcase to show that decoding keyframes is now working (mostly) correctly.
It would be great if they moved it forward so that it supported WebM so that one doesn’t need to rely on the web browser developer to update their browser – it will also be good for those running browsers before Internet Explorer 9 as well. Reminds me very much of the vorbis audio player written in Java on Wikipedia
AmigaOS obtained WebP datatype the day after it was announced so the system and any application (that uses datatypes) can “view” webp images
http://freesoftwareando.com/wp-content/uploads/2010/10/webp3.png
Did the Java Cortado applet really help the adoption of Ogg Theora?