Gree - 3d graphs (of json or javascript)

Experimenting on a new project called 'Gree' (from GRaphs with thrEE.js) to display and edit 3d graphs of json data or sourcecode. Motive is, that complex interconnected networks are difficult to display in 2d, e.g. edges overlap. 3d should improve visibility. To best utilize this, stereoscopic view (e.g. via vr device) is needed, since else the graph stays 2d projection. Currently there are 2 applications. The first is a general 3d graph tool. Graph data is represented and editable in json format. The graph can be modified by dragging its nodes.
► Gree Json

Second application generates 3d graphs of javascript sourcecode and vice versa. Why make 3d graphs of sourcecode? Code (display/editing) can be in a way redundant, because everytime a function is called, its name must be written. So a function name can appear multiple times. Alternatively a function could be represented as graph node (its name only displayed once) and everytime it is called, an edge to that node is drawn. This project tries to go that direction. Here an edge between 2 function nodes is drawn if one function is called from the other. For complex code with lots functions this can give a quick overview of code semantics. 3d positions of nodes are stored as comments above related functions. If the graph is modified by dragging its nodes, javascript can be generated with updated position comments. Javascript is parsed with acorn.js and generated with escodegen.js.
► Gree Javascript

Danger on the floor

In programming languages (tested in javascript and perl) you will get:

6*1.9*5 == 6*5*1.9 -> false

Because of calculations errors during floating point operations, the expression values differ by a very small amount. Here we get 57 and 56.9999... Floating point operations are not associative. One can work around this imprecission by never directly comparing floating point numbers, but always calculating with a small tolerance. Like this:

Math.abs(6*1.9*5-6*5*1.9)<0.00001 -> true

Now, when you use the floor function, you will get this:

Math.floor(6*5*1.9)-Math.floor(6*1.9*5) -> 1

The small floating point value difference has grown to 1. The difference is now substantial and might make a program do unexpected things. So, how to handle the floor-function here ? One could add a small value before applying floor. But then the value could grow too big and the floor-result is flawed again. The problem is, that the floor function cannot known if a value like 56.9999.. is a calculation error or deliberately constructed. In my opinion there is a systematic danger with using floor-function, because floating point numbers are imprecise, while the floor function has a big result-difference, dependent on a precise number. So in dealing with floor-functions there are this conclusions:

• One should try to avoid imprecise floating point operations. Maybe calculations can be done with fixed point or fractional numbers.
• If you have imprecise floating point numbers, dont use the floor function.

Drawing with Java

For Wloom I needed a transparent radar background image. Since I am not used to a vector-paint-programm, I 'drew' the image with java, by programming following small program. At first it creates an image, then it draws the radar shapes and saves everything as transparent png. Ingame the radar will look like this.

import java.awt.*;

import java.awt.image.*;



public final class Drawer {

  public static void main(String [] args) {

    try {

    BufferedImage i=new BufferedImage(300,150,BufferedImage.TYPE_INT_ARGB);

    Graphics2D g=i.createGraphics();

    

    g.setRenderingHint(RenderingHints.KEY_ANTIALIASING,RenderingHints.VALUE_ANTIALIAS_ON);

    

    g.setColor(new Color(0,0,0,100));

    g.fillArc(10,5,280,280,0,180);

    

    g.setColor(Color.black);

    g.setStroke(new BasicStroke(5,BasicStroke.CAP_ROUND,BasicStroke.JOIN_ROUND));

    int r=140;g.drawArc(150-r,150-r-5,r*2,r*2,0,180);

    g.drawLine(10,145,290,145);

    g.drawLine(150,5,150,145);

    g.setStroke(new BasicStroke(3,BasicStroke.CAP_ROUND,BasicStroke.JOIN_ROUND));

    r=95;g.drawArc(150-r,150-r-5,r*2,r*2,0,180);

    r=45;g.drawArc(150-r,150-r-5,r*2,r*2,0,180);

    g.drawLine(51,46,150,145);

    g.drawLine(249,46,150,145);

    

    g.setColor(new Color(100,200,0));

    g.setStroke(new BasicStroke(3,BasicStroke.CAP_ROUND,BasicStroke.JOIN_ROUND));

    g.drawArc(10,5,280,280,0,180);

    g.drawLine(10,145,290,145);

    g.drawLine(150,5,150,145);

    g.setStroke(new BasicStroke(2,BasicStroke.CAP_ROUND,BasicStroke.JOIN_ROUND));

    r=95;g.drawArc(150-r,150-r-5,r*2,r*2,0,180);

    r=45;g.drawArc(150-r,150-r-5,r*2,r*2,0,180);

    g.drawLine(51,46,150,145);

    g.drawLine(249,46,150,145);

    

    g.dispose();

    javax.imageio.ImageIO.write(i,"png",new java.io.File("radar.png"));

    } catch (Exception e) { e.printStackTrace(); }

  }

}

Blog/Diary concept, notes on JEditorPane

For notes on projects and other stuff I'm working on a blog/diary application. As other blogs the app maintains entries, that can be marked with tags. In the following some concepts are described.

• 2 Renderers. Currently the blog has 2 renderers, which display the entries. Both are written in Java. The first ([1] in the picture) is completely self-written. Thus arbitrary concepts can be tested with this renderer, e.g. taglines (more about that below). The second renderer ([2] in the picture) uses html, which is displayed with the Java html component JEditorPane. This html frontend might be a starting point for a later online version of the blog.
• Sticky tags. For todo lists or important stuff to be rememberered always there are sticky entries ([3] in the picture). They are implemented using a 'Sticky' tag. The blog renderer draws all entries with a 'Sticky' tag highlighted and on top of other entries.
• Checkboxes. For todo-lists checkboxes in entries might be useful, that can be checked if a task is done ([4] in the picture). In this app checkboxes are implemented in the following way: The texts "[_]" and "[X]" within an entry make the blog-app render a unchecked/checked checkbox at this position within the text. If the checkbox is clicked the entry text is changed, "[_]" is replaced by "[X]", and a timestamp is added to the text. Clicking a checkbox thus is a special way of editing an entry. If the entry has a 'Todo' tag and if with a checkbox click all checkboxes of the entry are checked, the entry automatically looses the 'Todo' tag.
• Taglines. To visually distinguish entries of different topics (with different tags) there are taglines ([5] in the picture). This are lines between entries of specific tags with a special color for each tag. The tag-text is drawn besides the entry with the same color. The lines blend out if they are drawn behind entries that dont carry the tag of the line. An older version of taglines is described in this previous blogpost.

Some general notes on JEditorPane: This component is a part of the quite old Java Swing Api, hasnt changed in years and only supports Html 3.2. Nevertheless imho its a very useful lightweight html renderer (opposed to gecko/webkit bindings), useful for structured/formatted output or to render complex gui layouts. The standard approach to Gui layouts, LayoutManagers, is probably hard to implemented for this blog layout, with lots fonts, floating texts and tables.
JEditor renders html-checkboxes as Swing component JCheckbox. This checkboxes can be accessed via jEditorPane.getComponent(i). This will return a java.awt.Container whose first component is the checkbox:

JCheckbox jcb=(JCheckbox)((Container)jEditorPane.getComponent(i)).getComponent(0);

Now eg. listeners can be added to the Checkbox, that inform, if it is clicked. Following link helped to figure out checkbox access: http://www.thatsjava.com/java-swing/12595/

Skybox algorithm

For the Wloom project a skybox was needed. A skybox is a large box around a scene, with sky texture. The textures of the 6 planes of the box can be calculated from a single picture.

The algorithm for this transformation is outlined as follows: For every texture point of the box-planes calculate two angles relative to the center of the box: a horizontal angle ax, where value 0 represents north, PI/2 east, PI south and 3PI/2 west; and a vertical angle ay, with a range from value 0 (=top) to PI (=bottom). From the original picture the color at the coordinates of the two angles is now taken and drawn towards the texture-point of the box-plane. Below the exact algorithm, written in Java, is listed.

for (int y=0;y<=w;y++) 
for (int x=0;x<=w;x++) {
  double xh=x-w*0.5;
  double lh=w*0.5;
  double ax=PI/4+Math.atan2(xh,lh);
  double ay=Math.atan2(Math.sqrt(xh*xh+lh*lh),-y+lh);
  b.setRGB(x,y+w,getRGB(ax*biw/(PI*2),ay*bih/PI));
  b.setRGB(x+w*2,y+w,getRGB((ax+PI)*biw/(PI*2),ay*bih/PI));
  
  ax=PI/4+Math.atan2(lh,-x+lh);
  b.setRGB(x+w,y+w,getRGB(ax*biw/(PI*2),ay*bih/PI));
  b.setRGB(x+w*2,y+w*2,getRGB((ax+PI)*(biw-0.5)/(PI*2),ay*bih/PI));
  
  double yh=y-lh;
  ax=3*PI/4+Math.atan2(xh,yh);
  ay=PI/2-Math.atan2(lh,Math.sqrt(xh*xh+yh*yh));
  b.setRGB(x+w,y,getRGB(ax*biw/(PI*2),ay*bih/PI));
  ax-=PI/2;
  b.setRGB(x+w,y+w*2,getRGB(biw-1-ax*biw/(PI*2),bih-1-ay*bih/PI));
}

The shown skybox is used in the next version of the WebGL game Wloom, which will be posted soon.

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.

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'.

Does bytecode become obsolete?

Or, more provocative: Will Javascript substitute Java? Java has a certain technical infrastructure, it utilizes bytecode. This exists for following reasons: In the history of programming languages at first there where interpreted languages, e.g. Lisp or Basic. They where slow but portable. Then there came languages like c and c++, where source is compiled to systemspecifc binary. They were fast, but unportable. With Java and bytecode a quite fast AND portable solution emerged. Java source is compiled to system-independent bytecode, which then is executed by the java virtual machine. With later versions of Java, to increase execution speed, just-in-time (jit) compilers were introduced. They compile the bytecode on the fly to systemspecific binary, which than runs faster. Besides the ecosystems of compiled languages, interpreted languages persisted. Script languages like Javascript are there to e.g. control compiled programms or bytecode.

Recently jit-compilers for javascript appeared (Google V8, Mozilla Tracemonkey). Thus Javascript becomes fast and portable, like java, but without bytecode. Bytecode now seems to be an unnessary intermediate step during programm execution. Bytecode means more complexity in IDEs and in language execution. If a jit-compiler works with sourcecode directly, not with bytecode, possibly more optimizations can be done (without the additional abstraction step bytecode). If you get the same results with a less complex solution, you should apply it. With faster script languages, also there will be no need to separate programm logic into scripts and compiled functions. One advantage of bytecode might be that you can have different programming language compiled to it and than be executed on the same virtual machine. Like with JRuby, Jython, Scala than run on the java virtual machine. If you ommit bytecode and want to have the same flexibilty, the execution engine (with the jit-compiler), must be able to read different types of languages. Future will show if that is feasible.

Aside from the technical aspect, lets look at usage fields of Java and Javascript. At first Java was meant to be for the desktop. This didnt fully work out, e.g. Java applets in general couldnt compete with alternative approaches like flash. Java though became very strong on the server. Javascript was also originally there for the desktop, with its improving performance and the new <canvas> html-tag it can increasingly compete with flash and java applets. As of lateley Javascript spread also to the server (e.g. node.js). Thus, also from this point of view, it seems, that Javascript pushes into Java territory.

Two final notes: First, you may replace the term 'java' with 'c#/.net' (or other bytecode/intermediate language platforms) in this text. Second, this considerations only apply to the far future, currently java cannot be replaced by javascript, because of its superior stability, performance, distribution and api. Also, different languages/platforms will stay (in niches). In my perception java/c# (also called managed code) superseded c++ (unmanaged code), yet c++ still exists. In a comparable manner Javascript will displace Java/C#, but all will stay (for now).