Lively3D released!

Lively3D is three dimensional windowing environment implemented in WebGL with help of GLGE-library. It features embedding of canvas-applications, customizing 3D-scenes and persistence of desktop state.

Lively3D provides API for third party developers, who can develop additional canvas-applications and 3D-scenes which are embedded with implementation of interface functions. These functions are designed in such way that the implementation requires minimal knowledge of the environment itself. Applications and scenes are deployed in shared Dropbox-folder, so that developers can collaborate and deploy their code without constantly updating files on the server hosting Lively3D.

Most of the applications were developed by summer coders and are described in previous blog posts. Two additional scenes are available for initializing in the user interface.

All code is MIT licensed and available in Github. Documentation of library interfaces is located at Docs Running environment is testable in Lively3D

HTML5 Security

Security in HTML5's all new features have generated quite a lot discussion lately in different internet forums. There have been comments on both good and bad sides of the new features and some discussions have turned into debates whether it should be the specifications or the coders responsibility to make their web pages safer.

In my opinion, as a coder, it is always a good thing to know about the security side of different web technologies, whether they are safe or not.

The best analyses I have found so far on HTML5 security are the following reports:

ENISA (European Network and Information Security Agency) have published a 60 pages long security analysis of next generation web standards, in which they address 51 security threats in detail. Full report available here.

Also a research report by Trend Micro issues similar threats and presents an example scenario on generating a botnet with HTML5 technologies.

Another good sites to find out more about HTML5 security are http://html5sec.org/ and HTML5 Security Cheatsheet Project websites.

Rendering HTML on Canvas

Robert O'Callahan writes in his blog about a workaround that allows to render HTML on Canvas element using SVG:

The trick is to create an SVG image containing the content you want to render, in this case a containing HTML, and draw that image to the canvas. Constructing the SVG image as a data: URI lets you compose the content dynamically without requiring an external resource load. There is nothing tricky going on here; this feature works exactly as it should according to the specs.

Blog post
Demo

There is also another project that aims at rendering HTML on Canvas. Niklas von Herzen has created a JavaScript library to solve the issue.

Project website

Project on GitHub

Experiencing with Canvas, HTML5 and WebGL

During the summer four trainees did little games as an introduction project to JavaScript, Canvas, HTML5 and WebGL. Four games developed were Space Attack, Jump, Mouse and Bullet.

• Space Attack is an arcade type shooting game where player controls a space ship and destroys enemies.




• Jump is a simple 2D platform game where player collects coins and tries to avoid falling down.




• Mouse is a reaction game where player controls a mouse character, tries to collect cheese and avoid hitting cats in a restricted area.




• Bullet is another reaction game where player has to counter-attack enemies with correct types of bullets.

Games were done without any experience of web programming, JavaScript or HTML5. When games were ready we decided to do some research and comparisons between different technologies that could be used composing similar games.

Two of the games, Space Attack and Mouse, were redone in traditional way using just CSS styles, HTML and JavaScript (no Canvas involved) and other two games, Jump and Bullet were redone with WebGL. Performance, memory usage and code complexity were compared between the original compositions and remakes.

Performance

For measuring the percentage of time used in rendering we used profiles from Chrome's developer tools. Measurements showed that the performance differences between implementations were small. Traditional implementations were from 3% to 8% more efficient than Canvas implementation. Differences between WebGL and Canvas implementations were similar: WebGL implementations were up to 9% more efficient than Canvas implementations. We found out that the reason for Canvas being the most inefficient might be text rendering. In our games rendering a simple text showing scores during gameplay took from 35% to 87% of the time used in rendering.

We also tried to measure FPS of the games but it's not a trivial task when browser’s rendering loop dominates drawing. For Canvas and WebGL we could use Chrome's FPS counter with 2D-hardware acceleration to measure FPS, but for games that doesn't involve Canvas or WebGL Chrome's FPS counter can't be used. Chrome also limits FPS to 60, so differences between efficiency in Canvas and WebGL weren’t exposed in measurements.

MozPaintCount was another method we tried for measuring FPS but for Mouse game that uses mouse movements as a control MozPaintCount didn't provide reliable results. MozPaintCount gives the number of how many times the whole document is rendered and when you move the cursor, document is apparently rendered again. So for measuring game performance MozPaintCount weren't the right tool.

One huge problem of comparing FPS of program in browser is that there aren't tools that works for Canvas, WebGL and traditional programs and are available in several browsers. MozPaintCount method works only in Mozilla Firefox and Chromes FPS counter is only available in Chrome so reliable and comparable results can't be provided easily.

Memory Usage

Memory usage we explored with Timeline from Chrome's developer tools. Between Canvas game and traditional web game there isn't a significant difference in memory usage but between Canvas and WebGL the difference is notable. WebGL implementations uses 2-3 times more memory than Canvas implementations. In Canvas games the memory usage were mostly under 10 MB when in WebGL games it was over 20 MB after games had been running approximately 15 minutes.

Code Complexity

Measuring code complexity were a hard task because, like in measuring FPS, there aren't good tools or any tools at all for complexity analysis for JavaScript or HTML. One tool we managed to found was jsmeter. Jsmeter provided some results but it couldn't handle source code that was divided in more than one file. Even though we couldn't do complexity analysis we draw some conclusions about complexity based on amount of code lines.

Just based on amount of code lines WebGL implementations were the most complex. We didn't use any library or framework for WebGL implementations even tough there are libraries to hide away WebGL's syntax and complexity. Between Canvas and traditional implementations there weren't significant differences in complexity. Traditional implementations have usually less JavaScript code than Canvas implementations but more lines written in HTML and CSS.

Amount of JavaScript code lines

	Canvas	Traditional	WebGL
Space Attack	573	533	-
Jump	918	-	1458
Mouse	830	798	-
Bulletgame	1041	-	1777

VNC Client in Lively3D

Here is a short video demo about VNC client in Lively3D world. The VNC client used is noVNC.

Angry Birds in Browser with WebGL

Angry Birds is a puzzle video game developed by Finland-based Rovio Mobile. Recently it has been ported for web browsers. The implementation uses WebGL for rendering the graphics.

http://chrome.angrybirds.com/

Most of the WebGL demos so far has demonstrated the 3D possibilities of WebGL but the WebGL version of Angry Birds shows how well WebGL can be used for 2D content as well. Another fine example of using 2D on WebGL is a nice space shooter game called X-Type http://www.phoboslab.org/xtype/, which uses WebGL-2D, a library that implements Canvas2D API on WebGL context. https://github.com/corbanbrook/webgl-2d

WebGL specification 1.0 released

The WebGL 1.0 specification was released this morning at GDC in San Francisco. Khronos has published a press release on the subject.

The press release also announces that Khronos is forming up a working group for WebCL to explore defining a JavaScript binding to the Khronos OpenCL™ standard for heterogeneous parallel computing. As said in the press release:

"WebCL creates the potential to harness GPU and multi-core CPU parallel processing from a Web browser, enabling significant acceleration of applications such as image and video processing and advanced physics for WebGL games."