Portable 3D-Browser-Applications UsingCross-Compiled Programming Languages

Christoph Muller, Fabian Gartner and Denis DikHochschule Furtwangen University

Faculty of Digital Media

Robert-Gerwig-Platz 1

78120 Furtwangen, Germany

{mch, gaertner, denis.dik}@hs-furtwangen.de

Abstract—Compiling from a more traditional programminglanguage into JavaScript to yield browser-capable applicationshas many advantages, such as re-using code and developerexperience on multiple platforms. Our open-source project ”Furt-wangen University Simulation and Entertainment Engine” provesthat cross-platform real-time 3D development in C# is possiblewith one target platform being JavaScript. However, specialdemands must be met to achieve the same level of performancewithout having to use additional browser plugins. This paperdescribes FUSEE and its core functionality and our approachesto compensate for any disadvantages in a cross-compiler scenariousing C# as the source language and JavaScript as the targetlanguage.

Keywords—3D Imaging, Web Based Real-Time 3D Applications,HTML5/WebGL, Visualization and Simulation, Virtual Reality

I. INTRODUCTION

Since its first implementation in browsers in March 2011,WebGL has become the basis for many web-based 3D projects.While WebGL grants developers access to the GPU’s hardwareacceleration power from within web pages, this is only a smallpart of the functionality required by contemporary real-time3D applications. Features such as scene graph management,animation and particle systems and procedural geometry gen-eration, to name only a few, are among the standard buildingblocks that make up the visual part of state-of-the-art real-time 3D engines. This functionality traditionally has to bedeveloped using robust programming languages compiled intocode which is most likely not suitable for cross-platform usage.

The only programming language generally available withinclient side browser content is JavaScript. Though syntacticallysimilar, programming in JavaScript is in many ways differentfrom programming in other languages such as C++, Java,or C#, especially when the functionality is required to yieldhigh performance on huge data sets as in all of the featuresmentioned above. Developers with background in real-time3D programming in one of the more classical programminglanguages will experience steep learning curves when trying toapply their knowledge to JavaScript. Furthermore, in scenarioswhere a browser application is only one platform to besupported (e.g. among Windows/Linux standalone versions),existing non-JavaScript code cannot be re-used easily withoutproviding additional browser plugins.

Fig. 1. The same FUSEE example app running on Microsoft Windows 7, inMozilla Firefox 26 and on an Android 4.2 device by Samsung.

II. FURTWANGEN UNIVERSITY SIMULATION AND

ENTERTAINMENT ENGINE

A proven approach to overcome the need to re-developthe same functionality in a different development environmentis to use a cross-compiler to translate existing code from alanguage like Java or C# into JavaScript. With this in mind,we started to work on a new educational and scientific projectcalled ”Furtwangen University Simulation and EntertainmentEngine” (FUSEE)1 at Furtwangen University in 2013. Theidea behind FUSEE was to create an open-source 3D en-gine as a proof of concept that state-of-the-art programminglanguages and techniques can be applied to cross-platformgame development. C# was chosen as the main programminglanguage for FUSEE because of its built-in support for valuetypes (structs) allowing programmers to control the memorylayout of complex data structures up to byte boundarieswithout ending up in automatically generated reference treeswith dereferencing overhead. Furthermore, C# contains all thefeatures of today’s cutting-edge computer-language conceptsand in many cases these features were first implemented in C#before other languages adopted them [1]. Among such innova-tions are support for properties with setters and getters, codeannotation for numerous applications up to aspect-orientedprogramming, enumerators with language support for loopsand enumerator implementation, generics on byte-code level,anonymous methods/lambdas/language integrated queries andlanguage support for asynchronous programming, to name onlya few. Only some of these features have made their way intoother languages such as Java afterwards, typically in a lessseamless way.

1FUSEE: http://www.fusee3d.org/

2014 International Conference on Computational Science and Computational Intelligence

978-1-4799-3010-4/14 $31.00 © 2014 IEEE

DOI 10.1109/CSCI.2014.125

713

2014 International Conference on Computational Science and Computational Intelligence

978-1-4799-3010-4/14 $31.00 © 2014 IEEE

DOI 10.1109/CSCI.2014.125

229

2014 International Conference on Computational Science and Computational Intelligence

978-1-4799-3010-4/14 $31.00 © 2014 IEEE

DOI 10.1109/CSCI.2014.125

229

2014 International Conference on Computational Science and Computational Intelligence

978-1-4799-3010-4/14 $31.00 © 2014 IEEE

DOI 10.1109/CSCI.2014.125

229

When FUSEE started, a few game engines written in C#already existed, but either those were not open source or theywere mere adoptions of existing game engines written in C++.Most of these existing engines did not consequently apply thefeatures given in C#, mainly because the code was a port of anexisting C++ engine. Other engines did not exhibit state-of-the-art rendering features such as shader programming very well touser code or had other design weaknesses. In addition, none ofthe existing engines were designed for the clean separation intoa platform-independent and a platform-dependent part. Thiswould allow cross-compilation of huge parts of the engineinto JavaScript, enabling game applications written on topof FUSEE to be automatically transformed into plugin-freeJavaScript/HTML-only web applications as shown in Fig.1.Trying to apply such concepts into an existing engine seemedmore complex than designing a new engine from scratch.

FUSEE was then further developed in lectures and in sci-entific research at our university. Basic and advanced featuressuch as scene and shader management, lighting, text renderingand sound and network functionality were implemented overthe last year - always focusing on being platform-independentor at least being able to provide platform adapters as describedin section II-A. Besides the web applications mentioned above,ports for Linux, Apple Mac OSX and Android using Mono asthe cross-platform .NET equivalent were successfully tested.Currently, FUSEE is still used for educational as well as forindustrial purposes, e.g. for visualization of results of scientificresearch in cooperation with the Fraunhofer Society in Freiburgim Breisgau, Germany.

A. Cross-Compiling and Platform-Dependent Implementations

There are many different cross-compilers available for alarge number of different programming languages. The twomost famous ones are Emscripten by Alan Zakai for cross-compiling LLVM bytecode (C and C++) into JavaScript andthe Google Web Toolkit (GWT) for translating Java intoJavaScript. Both cross-compilers are open source and free-to-use. Emscripten uses asm.js, a low-level subset of JavaScript,which allows almost the same performance in JavaScript com-pared to the original C++ source code, impressively shown bythe cross-compiled Unreal Engine running in Mozilla Firefox2

[2]. Furthermore, there are several cross-compilers for trans-lating CIL bytecode (i.e. .NET applications) into JavaScript,of which the three best known are Script#, Saltarelle andJSIL. For FUSEE we decided to use JSIL3, the only cross-compiler of those three which is open source as well as heavilymaintained by his author, Kevin Gadd. JSIL is specialized ontranslating applications written with Microsoft’s XNA frame-work which is something we do not use. We therefore removedor modified some parts while still profiting, for example fromJSIL’s asset system and its other functionality optimized forgame development.

However, translating code from C# into JavaScript requiresmore than just a cross-compiler. Important parts of a real-time3D engine are platform-dependent implementations, accessingOpenGL as the underlying graphics library. While WebGL issimilar to OpenGL in its core functionality of communicating

2Example by Epic Games and Mozilla: http://www.unrealengine.com/html5/3JSIL by Kevin Gadd: http://jsil.org/

Fig. 2. FUSEE’s workflow: Only certain parts are cross-compiled from C#into JavaScript with JSIL, while others are manual written implementations.

with the graphics card so that OpenGL code could somehowbe translated into WebGL code4, other libraries like OpenALwould break this automation workflow as they do not havean equivalent implementation in JavaScript. This problem issolved in FUSEE by exposing facade objects and classesto the user/application code. These facades then delegatefunctionality requests to platform-dependent implementationobjects. To decouple the facade objects from the platform-dependent code, an anonymous factory pattern is used, hidingthe platform-dependent objects against the facade objects. Inour case that means that the cross-compiler only translates theengine’s core and the user-written application from C# intoJavaScript as shown in Fig.1. Then, manual implementations(so-called ”Platform Adapters”) in the form of JavaScript filesare added. These scripts implement the same methods andvariables as in C# but use WebGL instead of OpenGL. Thesame solution is used for FUSEE’s audio, input, text andnetwork libraries.

III. CHALLENGES

Besides the manual implementations of the platform-dependent layers mentioned above, there are some other spe-cial demands to be met before or while cross-compiling real-time 3D applications. One issue which has to be dealt with, isthe overall performance of JavaScript. We set up a performancetest with a simple example application without any of theoptimizations we are going to describe below. We measuredthe time from starting the application until the initializationis completely finished, while dividing this process into foursteps: loading and initializing the engine and all libraries,parsing geometry with about 10,000 vertices defined in anOBJ Wavefront file, calculating the surface normals for thisgeometry and finally converting the geometry’s faces intorenderable data. The test was run on a state-of-the-art machinewith a quad-core 3.3 GHz Intel Xeon E3-1230 with 8 GBof DDR3-RAM and with Windows 7 Professional, x64 asthe operating system. We averaged the results of 100 runsof the standalone version and the cross-compiled equivalentin Google Chrome 31 and Mozilla Firefox 26 on the samemachine. Although this is not a fully scientific analysis, itgives a good overview of the current performance differencebetween our different target platforms.

4This would still require a lot of manual work to ensure the correct use ofslightly different methods.

714230230230

TABLE I. PERFORMANCE RESULTS ON DIFFERENT PLATFORMS

Task Windows 7 Firefox 26 Chrome 31

Initializing/Loading the Engine 530 ms 890 ms 980 ms

Parsing Geometry from an OBJ 45 ms 2,510 ms 6,110 ms

Calulating Surface Normals 310 ms 4,040 ms 17,190 ms

Converting the Geometry 55 ms 390 ms 1,700 ms

Total Time 940 ms 7,830 ms 25,980 ms

Table I shows the results of the performance test5. Besidesthe fact that our cross-compiled JavaScript applications areslower in general, the difference between Firefox and Chrome(7.8 seconds vs. 26.0 seconds) is surprisingly high. We arenot going to examine this difference in detail as browserdevelopers are already working relentlessly on improving theirJavaScript engines, meaning that this difference can changewith every new browser version. This also means that there isalways a maximum performance that can be achieved, mostlylimited by the JavaScript engine’s optimizer. Therefore, wewill describe what aspects an application developer can takeinto account when cross-compiling applications from C# intoJavaScript. There are different approaches to eliminate the timedifference between the web application and the standaloneapplication, some of which need to be part of the engine’score functionality, while others need to be respected whencross-compiling. Those optimizations will also reduce the gapbetween different browsers.

A. Initialization

The time browsers need for the initialization of the cross-compiled application is still within acceptable limits. Firefoxis about 1.7 times slower while Chrome is about 1.8 timesslower than the standalone application. This is not a noticeablelag especially as all three times are still under 1 second. Thebrowser needs to load and interpret 51 JavaScript files witha total size of about 6 MB. Before the test, we had alreadyreduced the file size of the six biggest of those files which workas interfaces for .NET’s System files (e.g. mscorlib) from about20 MB to 3.5 MB by removing unnecessary and redundantfunctionality. This could be improved further by only declaringnecessary parts and by additionally compressing those files toachieve a total file size of below 4 MB.

B. Parsing Geometry and Calculating Normals

The second step in our performance test was the reading ofgeometry from an OBJ Wavefront file. Those files, commonwhen sharing 3D geometry between engines and 3D graph-ics applications, contain, for example, information about thevertices, the faces and the texture coordinates of a mesh in ahuman-readable format. Parsing them means iterating throughthe complete file, while reading and adding the included datainto corresponding arrays. While parsing the 10,000 verticesmesh is fast in a .NET application with a time of around 45ms, this process needs much more time in JavaScript. Firefox31 completes parsing after 2,510 ms, whereas Chrome needsabout 6,110 ms for the same file.

5Not mentioned is the time required to load all files from a server beforeinitializing. Our cross-compiled files’ size is about 6 MB in total (not includingany assets). This is not a problem with state-of-the-art internet connections.

However, while only a small portion of the total time isneeded for this step, most of the time is required for thecalculation of the normals for a mesh. Unfortunately, someprograms such as Cinema4D do not include information aboutthe surface normals when exporting a mesh as an OBJ Wave-front file, thus they have to be calculated by the engine itself.This means again a high number of array operations whileiterating through all faces of a mesh to find correspondingvertices. In a .NET application the 310 ms needed for thisprocess are still acceptable for a single mesh but would bea problem when loading more than one 3D object or morecomplex meshes. Furthermore, Firefox is 13.0 times slowerthan the .NET application and Google Chrome needs 55.4times longer than the .NET application.

Both steps can be made faster by using several techniques,two of which are described in the next sections.

C. Serializing Geometry

A common approach to avoid repeating the same processover and over again is the serialization of already calculatedgeometry as described in [3]. This is an easy task withlibraries such as ”protobuf” by Google6. Available for manydifferent programming languages such as C#, Java or evenJavaScript, the user only has to declare his structs and classesto be serializable and identify them by a unique ID. Thetwo great advantages over the more classical way of usingMicrosoft’s classes such as the BinaryFormatter is the systemindependence and the smaller file size as protobuf does notneed to know the classes’ name while the C#/.NET serializa-tion implementation does. We have already used protobuf fortesting purposes in FUSEE for the serialization of data packetsin our network library implementation. Furthermore we testedhow serialization can speed up the initialization time. Parsinga serialized version of the 10,000 vertices mesh we have usedin the performance test above only requires about 120 ms.Although there is a protobuf implementation for JavaScript,this technique cannot be used in a web application as is.The structures of structs and classes are different after cross-compiling so that an automatic type cast on the deserializeddata would not work. However, an easy solution is a manualtype cast implementation. Standardized ”proto” files generatedby protobuf for .NET includes class IDs. With these IDs thetype of data can be identified, content can be recovered and theequivalent cross-compiled data structure can be returned. All inall, this process would still be a great deal faster than parsingthe geometry form an OBJ Wavefront file and calculating itssurface normals every time the application starts.

D. Accessing Raw Binary Data: Typed Arrays

Contemporary real-time 3D engines need to access hugesets of data in a very short time within nested loops, e.g. forthe calculation of normals mentioned above or geometry basedanimation such as skeleton or morph target animation whichrequires the alternation of many thousands of x-y-z vertex-coordinates per frame whereas terrain rendering requires thecreation of geometry patches from elevation on the fly and theseamless stitching of patches of different resolutions togetherin real time.

6protobuf by Google: https://code.google.com/p/protobuf/

715231231231

The most important thing in general, is to remove allunnecessary array operations, e.g. by storing returned valuesin variables instead of accessing the same index over andover again. While this is probably not a great issue in a.NET application it can significantly reduce the performanceof JavaScript. The reason for this is the way JavaScript storesdata in memory. One way to improve speed when working withlarge arrays is to store the data in contiguous memory blocksin order to support processor caching and to allow access toindividual data items from iterating loops in a very fast way.Programming languages like C++ or C# allow defining structsto specify the memory layout of individual data items and theninstantiate arrays of such structs to allocate contiguous memoryblocks [4]. Looping over struct instances and accessing structmembers then can then be reduced to simple pointer arithmeticby the compiler. Java and JavaScript work differently. In theselanguages, no inherent general syntactic elements exist to allowprogrammers to create arbitrary aggregations of objects laid-out contiguously in memory. Aggregations of non-primitivetypes in both languages are always references of objectspossibly being scattered all over the physical memory, resultingin bad caching performance penalties and in unnecessary andexpensive array-access and member-access operations. Thisbecomes even worse when those access operations are usedin chains, a typical situation in the cases mentioned above.

With the introduction of HTML5 and WebGL, JavaScriptwas expanded by a feature called typed arrays to handlecontiguous blocks of data [5]. While sufficiently useful whenused to exchange blocks of geometry data with WebGL, froma programmer’s point of view, handling geometry algorith-mically as the cases mentioned above, using typed arraysresults in poorly readable and maintainable code. Programmerscannot use the ”natural feeling” way of aggregating datain structures, instantiating huge numbers of structures usingarrays of structs, and accessing individual members using arrayindexing and object access operations. Instead, programmersmust handle individual member access of array componentsby self-implementing instance and member-offset calculation.Although the typed arrays specification defines some sortof programmer convenience in the form of the ”DataView”interface, we noticed in previous performance tests that currentbrowser implementations perform significantly worse whenaccessing typed arrays through DataViews, compared to ac-cessing a typed array directly. Again, the alternative is writingthe application in C# and using a cross-compiler which is ableto create data structures in JavaScript which store data in thesame way that C# does. While not every cross-compiler isable to do this, JSIL can use typed arrays for this purpose.Using the field attribute ”JSPackedArray” signalizes JSIL touse a completely different way to handle those arrays of structswhen translating C# into JavaScript.

We ran a separate test to gain an overview on what per-formance gain could be achieved by using typed arrays. To dothis, we declared a simple struct ”Vertex” which could handlea vertex’s x-y-z coordinates in three-dimensional space plus athree-dimensional normal vector and a two-dimensional texturecoordinate. This struct was then used for an array of structwith 1,000,000 random entries. We implemented the samefunctionality in JavaScript using a typed array (Float32Array)and finally we measured the time needed for accessing andmodifying each and every entry once. Again this test was run

100 times on Windows 7, in Firefox 26 and in Chrome 31 andunder the same conditions as the performance test describedin section III. The averaged results showed that Firefox 26and Chrome 31 were even faster than the standalone .NETapplication when using typed arrays, both needing 11 ms intotal, whereas the .NET application needed 17 ms for the sameoperations. In addition, both browsers were much faster thanthey would have been using a normal cross-compiled arrayof struct (Firefox: 850 ms; Chrome: 1,130 ms). These resultsprove that typed arrays are absolutely necessary when workingwith huge sets of data and that they can easily compete witha .NET application. Using typed arrays would speed up allgeometrical operations thus reducing the time needed for step2, 3 and 4 of our performance test described in section III.

IV. CONCLUSION

In this paper we have described only a few simple tech-niques which can greatly improve the overall performanceof real-time 3D applications cross-compiled from C# intoJavaScript. Combining them would compensate for most ofthe performance differences between a standalone .NET appli-cation and its equivalent cross-compiled web application. Inparticular, the significant difference in accessing memory usingtyped arrays versus the automatic output by current cross-compilers yielding chunks of non-contiguous objects scatteredall over the physical memory, shows the enormous potentialstill waiting to be exploited. All in all the results of ourperformance tests after implementing the optimizations, showthat web applications do not need special browser plugins toachieve the same level of performance as a .NET application.Furthermore, these results prove that cross-compiling from C#into JavaScript is a viable solution for re-using existing codewhile enabling applications to run on more than one platform.

Our next step will be the implementation of the techniquesdescribed in this paper in all important processes in FUSEE,for example by adding a more convenient asset system whichallows automatic conversion from OBJ Wavefront files toserialized geometry while cross-compiling the application fromC# into JavaScript.

ACKNOWLEDGMENT

The authors would like to thank the Faculty of DigitalMedia at Furtwangen University for providing the resourcesand we would like to thank Kevin Gadd, author of the JSILcross-compiler, for JSIL and his support.

REFERENCES

[1] K. Radeck (2003, Oct.). ”C# and Java: Comparing Programming Lan-guage”. Microsoft [Online]. Available: http://msdn.microsoft.com/en-us/library/ms836794.aspx [Accessed: Nov. 17, 2013].

[2] A. Zakai (2013, Oct. 22). ”FAQ”. GitHub.com: Kripken/Emscripten [On-line]. Available: https://www.github.com/kripken/emscripten/wiki/FAQ[Accessed: Nov. 17, 2013].

[3] K. Maeda, ”Performance Evaluation of Object Serialization Libraries inXML, JSON and Binary Formats” in 2nd Int. Conf. on Digital Informa-tion and Communication Technology and It’s Applications (DICTAP),Thailand, 2012, pp. 177-182

[4] P. S. Deshpande and O. G. Kakde, C & Data Structures. Hingham, MA:Charles River Media, 2003.

[5] The Khronos Group Inc. ”Typed Array Specification (Work in Progress)”.khronos.org [Online]. http://khronos.org/registry/typedarray/specs/latest/[Accessed: Nov. 17, 2013].

716232232232