Canvas graph demo, Usecase: Football results

FC Hansa Rostock
Kickers Offenbach
Wacker Burghausen

St. Pauli
HSV
FC Bayern München

On the left there is a interactive canvas graph demo, showing football results. You can switch highlighted graphs by mouse-clicking on the corresponding description. Since all the javascript is written in one line, all content of this blogpost could be uploaded to blogspot, there is no iframe needed here. Soon there will be a more advanced canvas demo and I'm also working on a webgl+bullet.js demo. Stay tuned! :)
Update: I made the graphs animate and added functionality: If the mouse moves over the graph, detail information is displayed.

Twitter client concept: Refer arcs

In my current twitter client, to follow conversations between users, I often have to scroll and search to find the corresponding tweets. To make this process more comfortable (especially the search part), I introduced refer arcs into a twitter client which visually connect tweets that probably refer to each other (replies, retweets).
On the right there is an animated gif, which demonstrates this technique. The updated twitter client ('Twaja') will be downloadable soon.

Thoughts on other stuff. Three recent (in my opinion) questionable developments in computation:

• Oracle sues Google over Java. Obviously the new owner has other priorities then the old one. Java might loose people working with it.
• Google and Verizon propose new policy to constrict net-neutrality. This might be a step toward the end of the open net.
• Google stops Google Wave. After just a year this innovative project is canceled. Thats quite few patience, reminds of canceled Google Lively.

End of rant. :)

What I like about Javascript (compared to Java)

This list was assembled, while I was coding some Javascript projects (see blogposts below), and is of course only a subjective view:

• dynamic typing: simpler declarations, no casts, no interfaces, less keywords, simpler syntax (but I see possible drawbacks: its may be more error prone, and probably less runtime performant)
• "this" is mandatory to access object-variables, in java its optional. This is more clear semantics and promotes the use of local variables.
• simple and powerfull Array and Hashtable (instead of Java's multitude of Array,Vector,List,Collections..)
• prototype based object system. its more flexible than javas class based system, e.g. you can add methods to existing objects.
• last but not least: it runs everywhere in the browser, quite like java, but in a more straightforward and powerfull way (direct dom access, not like a plugin).

Still, Java keeps being great, but above points make Javascript very much interesting, imho.

bullet.js - Javascript Ragdoll Physics

I ported more classes from JBullet to Javascript Physics engine bullet.js, wrote some new and assembled a new canvas demo showing javascript ragdoll physics: Click. Now almost all classes from JBullet are ported, except some for vehicle physics. The size of bullet.js is now about 330kB. The demo shows on my pc using Chrome ca. 40fps. The current drawing (software 3d using canvas) is not very performant, so soon there will be bullet.js+WebGl demos.

bullet.js - Javascript Physics Engine

I finished porting parts of the JBullet and Vecmath library from Java to Javascript. As the result there is another 3D Physics Engine for Javascript named bullet.js (because its based on the Bullet Physics Engine). Its size is about 200kB. Here is a canvas-demo, showing the engine in action. The demo consists of the same animation with 20 boxes as the java physics demo, I posted before. Thus one can compare the different performances. On my computer I get following frames per second:

• Java: 300 Fps
• Javascript Chrome: 45 Fps
• Javascript Firefox 4b1: 10 Fps
• Javascript Firefox 3.6: 3 Fps

This shows 2 points. Point 1: Google Javascript is quite performant, Mozilla must still improve things. Point 2: Although Javascript execution speed has great improved in the last years, there is still a big performance gap wrt. Java. Maybe javascript will never run as fast as java, because of its dynamic nature/typing? Time will tell. :)
Anyways, currently there is a canvas demo, but the real purpose of a 3d javascript physics engine would be WebGl. So there will be WebGL demos soon on this blog.
A issue exists with the javascript port: the boxes in the demo sometimes show strange behavior, they bump from the ground and fly through the air.. In the java demo they dont do that, so there must be a bug in the Javascript code. If there is someone who actually understands how the bullet engine works (I dont, I just ported it :) it would be nice, if I get help to find the bug.

WebGL demo: normalmaps, shadows, scripting

The demo uses the glge-library and shows

• normalmapping,
• shadows and
• scripted lights and animation

for WebGL. The building is inspired by a church in Schwerin.

Java Physics Demo: Boxes

Start applet.

This demo uses parts of the the JBullet and the Vecmath library. I extracted essential classes and put them all into 1 java source file. Thus this demo dont needs external libraries.

On Objectstacks
I also changed the used JBullet parts, so that they dont use Objectstacks. Objectstacks were introduced to manage temporary objects in a threadsafe way. There are 3 possibilities to deal with temporary objects:

• 1) Just instantiate a temporary object as you need it. Problem: this can result in a lot instantiated objects, garbage collector has alot todo, runtime performance might drop. Though, intelligent jit-compilers could possibly handle multiply temporary instantiations and could in a way inline them..
  
• 2) Add (private) auxiliary objectvariables to the class. You can use this objects in computation and dont need to instantiate new ones. Problem: if different threads invoke the same method at the same time, an object could be used twice, with unexpected results. This approach is not thread-safe.
  
• 3) Use objectstacks. Retrieve auxiliary objects from a pool and return them to the pool, when computation is over. This way in most cases only limited number of instantitions is needed (opposed to possibly unlimited instantiations in approach 1) and this method is threadsafe (opposed to approach 2).

The original JBullet library uses objectstacks. In this demo I omitted them, because the original approach requires an instrumentation step in the build process. During this step auxiliary classes are generated using an ant-build-file. A simple compile doesnt work. For sake of simplicity I thus dont use objectstacks here, but above second technique. Thus this demo is not thread-safe, but its usecase is only single threaded, so it doesnt matter.

How to build

• Make sure, that a JDK is installed.
  
• Put the source file into a directory 'net/plsw/bullet'.
  
• Compile it with 'javac net/plsw/bullet/BoxDemo.java'.
  
• Run it with 'java net.plsw.bullet.BoxDemo'.