EGL Rich UI Hub

Please join me on a trip through time.

Thirty years ago

Back in the late eighties I saw a presentation by David Ungar on animation algorithms implemented in the Self programming language interface. I was blown away by the innovative ideas implemented by him and his research team. Here are some of the though-provoking animations implemented in Self:



Twenty years ago

Michael Jordan starts with the the Looney Toons cast in the movie called "Space Jam". Computer animation in movies has come a long way since then. Especially the last few years, the distinction between reality and animation is becoming increasingly blurred. A similar trend is happening in the gaming industry. Think back how the characters moved in classics, such as Space Invaders, PacMan, and Tetris. Each moved in a linear path and the animations can only be categorized using my 12-year old son's favorite phrase as being "so obviously fake!".



Ten year ago

In one of the most iconic scenes in the "Matrix" movie, Keanu Reaves learns how to dodge bullets. He moves at super-human speed and twists and turns to avoid the bullets coming at him at roughly the speed of sound.

Luckily, the directors of the movie, the Wachowski brothers, have enough empathy with the poor audience to show the scene in slow motion. Here is a still fragment:



Notice the blurry motion suggesting movement. What you cannot really see in the still of course, is how the computer animation wizards used real-life laws of physics to "correctly" model the actual movements. Newton already taught us the lesson of inertia. Things don't tend to move in a linear fashion, but they take time to get going, then they move, and then they slow down again using some mathematical function.

Three years ago

The iPhone is launched. It is immediately known for bringing many user interface innovations to the general market. One of them is the "swipe". To switch between images, you move your finger over the touch screen, and the iPhone takes over by finishing your gesture by making a nicely controlled animation of the old and new images scrolling on the screen. Few people notice the math that goes behind that simple scrolling, yet it is crucial to making the animation believable. By providing a good animation, the user actually feels like they are dragging a physical object. And for those that still feel like they need to practice, there's an app for that too:


iPhone app: Finger Sprint, only $0.99.

Today

Animation comes to EGL Rich UI

By abstracting the JSTween library, it is now quite easy to animate browser objects believably and move them or resize them using a almost-realistic animation. One example can be seen at http://eglplanner.com.



The animation in the ad at the top right is using the following mathematical function to reveal and hide the underlying links:

strongEaseIn = function(t, b, c, d){
    return c * (t /= d) * t * t * t * t + b;
}

Don't ask me to go into the details here. EGL is designed for hiding complexities like those mathematical functions, and we very nicely wrap them into an API that can be used like this:

animator Animator{ widget = rightSegment, duration = 2000 };
animator.moveTo(265, 0);
animator.moveTo(6, 0);

This defines an animator object, with a target widget and a duration. The widget can be moved to a certain location simply by calling the moveTo operation. It will then the animation function that was specified for the animator, with strongEaseIn being the default, and move it there in 2 seconds.

Doing animation in JavaScript is extra hard because the way the browser renders the page. There is only one JavaScript thread. Whenever it runs and DOM operations are applied, they are all buffered and not yet drawn. Not until the thread returns is the document rendered and is something drawn on the screen. This makes it hard to do an animation in a for-loop for instance. All the intermediate steps are lost, and only the last motion is rendered. Not what you want....

Therefore, the underlying jstween library will split up each animation step, and run the individual animation fragments in a separate job. Basically, it does this until it is done: move-render-wait-move-render-wait-move-render. These animations can be interleaved, and the animation can be combined as a result.

The ad shown above is included in the project attached to this blog entry. In addition, a second example is included that shows all the different animation functions:



When the user clicks anywhere in the grey box, the yellow box is moved to that position, while being resized at the same time. You should try out the real sample here.

Attachment: com.ibm.animation-2009-12-15.zip (43K)

Lately, I have been getting some questions on scalability of EGL Rich UI, and especially how well the architecture supports many asynchronous services being called at the same time.

So, I decided to write a sample with a service looking like this:



Then I call that service however many times the end user likes:



The end result for 30 tries looks like this:



It finishes the whole calling sequence instantly. I'd say within 0.5 seconds or close to that. It is extremely hard to see the browser draw the results. It actually feels like it finishes drawing before I raised my index finger off the mouse button

To increase the stakes, I tried a more interesting number of service calls. So I entered 1,000 calls, fully expecting either my browser or Tomcat to give up and die:

However, 1,000 calls are still comfortably handled in around 2 seconds. Note that both the browser and Tomcat run on the same Thinkpad T60. Actual network delays will produce different results when repeating this on a service deployed on a production server.

As you can see the answers come back in a "random" order. This is to be expected. The first letter in "Ajax" stands for "a"synchronous, and that is actually how the messages are sent out, handled, and received again by the browser.

Finally, I tested the above little sample with 10,000 concurrent service calls, to see when the ship would sink.

This final experiment took a while longer, and Chrome kept asking me if I wanted to kill the runaway script while it was sending out those 10,000 Ajax calls

Eventually the whole thing finished. Making 10,000 calls this way took about 1 minute to send out all those requests, and then about 2 minutes to receive all the incoming results. Clearly, my algorithm exposed some non-linear performance.

Therefore, I rewrote my sample just a little bit, to send the same messages in 10 separate batches and not to print out every single message that came back. This removed an obvious bottleneck in the browser, and likely gave the browser's garbage collector the chance to catch up.

With the 10 batches, it took only 24 seconds on average to make 10,000 calls. Looking at the performance chart I could see that a lot more was happening in parallel now also, as both CPUs in my dual-core machine were running at 100% now.

For the tests with 100,000 and 1,000,000 calls I used 100 and 1,000 batches respectively.

Here are the end results in a chart:



As you can see above, you can expect to be able to make a million services calls in 2,400 seconds. This comes down to over 400 calls per second between a dedicated server and a browser. You hopefully agree that 2.4ms is a really good response time for a web service.

Transaction rates will go down when the distance between the browser and the server is larger. They will go up when edge caching and real production hardware is used, instead of a laptop. In other words, your mileage will vary.

In "real" world scenarios, my experience is that web service calls take anywhere between 40ms and 2 seconds to make the round trip.

Hopefully this experiment and its outcomes gives you some confidence about the scalability of EGL Rich UI. Being able to make 400 service calls per second is more than enough for any application I personally can imagine.

In an earlier posting I mentioned the importance of using external style sheets to separate look and feel from behavior in EGL Rich UI applications. In practice, some EGL Rich UI users have experienced challenges in keeping the CSS syntactically valid. The CSS editors that come with Eclipse/WTP, and which we use without change in RBD, do not validate the CSS that is being edited inside them. And RBD does not add any extra help either.

Not having CSS validation in our tooling makes CSS error detection and debugging more difficult. The best technique we can come up with is to use Firebug in Firefox, but that requires quite some extra setup and work by the developer. A very useful online service called Jigsaw is also available at w3.org. You simply enter your CSS into a form, and the service will tell if it is valid CSS or not. Here is the service with an intentionally invalid sample:



After pressing the "Check" button, you will see a result looking like this:



While using the Jigsaw service, I was thinking that the Rich UI application that I was developing could easily validate itself by making a REST service call to the same Jigsaw service, passing its own CSS files as an argument. So, I wrote an EGL Rich UI widget (without needing any JavaScript, of course). It basically does the following:

1. Inspect the document body, and find all elements with tag name equal to "LINK".
2. Download each CSS file and send it to the CSS to the Jigsaw service.
3. Parse the result by finding all the "td" elements with class equal to "parse-error" (which is how Jigsaw reports its errors).
4. If we find any error, report them. Otherwise, be silent.

After including the widget into our EGL Rich UI application that uses the bad CSS, we now see an error message appear automatically when we run the application:



The widget itself defines a VEWidget annotation, so you can easily drag and drop it from the palette in the visual editor (make sure to hit the "refresh palette" button on the design toolbar). Here is how the widget can be used:

handler CSSErrorsDemo type RUIhandler { 
		initialUI = [ validator ], 
		includeFile="css/bad.css" // located in WebContent directory!
	}
	validator css.CSSValidator{};
end

The actual widget is shown below. Copy it to your workspace, feel free to rename the package name. Let me know when you find any problems with it.