13. 3D in a Web Browser (5/6)

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

13.6GoogleNativeClient 219

applications. Currently focused mainly on supporting a large subset of the x86

instruction set, this project also targets other CPUs, such as those based on ARM

technology, and it should be available to integrate with any browser, either na-

tively or as a plug-in.

This can be viewed as a meta plug-in that allows all the existing plug-ins that

can obey the security issues (limited access to local drive, no self-modifying

code, etc.) to be executed directly. Therefore, ShiVa and Unity will be perceived

as a “no plug-in” version once Google Native Client becomes pervasive. It will

be ideal to have a single plug-in (Google Native Client) that provides maximum

performance and flexibility to all the applications, while providing “no plug-in”

usability to the user. Native Client could very well be the ultimate cross-platform

technology development, provided that vendors do not find a way to oppose its

deployment (Apple may block this the same way it is blocking Flash on their iOS

devices).

Unity (and soon ShiVa) can accept C/C++ libraries that can be linked with

the game to provide additional optimized functionality that is too CPU-intensive

to be done with the scripting language. But this has not been mentioned thus far

in this chapter because it is not useful for the development of web games, as

those libraries are not linked with the standard web plug-in and are therefore not

available to the game running on the web. But with Google Native Client, it will

be possible for the game developer to provide his own libraries, compiled with

the Google Native Client GCC compiler, and link those dynamically with the

game running on the web.

Native Client also offers an audio and graphics API. The 3D hardware-

accelerated API is OpenGL ES 2.0. It is really nice that Google did not go ahead

and provide a standard API that offers shader programs and a relatively slim lay-

er over the GPU. Kudos to Google for choosing to embrace a standard, OpenGL

ES, rather than inventing a new graphics API. Choosing the ES version of the

API (as opposed to the desktop version of the API) enables the same graphics

code to run on any desktop, mobile, or tablet hardware.

The problem with this choice is that although OpenGL ES 2.0 can be imple-

mented rather easily given an OpenGL 2.0 driver, only 35 percent of Windows

XP computers (XP currently represents 60 percent of all computers [27]) have an

OpenGL 2.0 driver, and the others have drivers that are not very stable. On mo-

bile platforms, there is a large dominance of OpenGL ES 2.0, so in order to unify

the terrain, Google has created ANGLE, an implementation of OpenGL ES 2.0

on top DirectX 9, which is well supported on all the desktops. This includes a

shader translator from GLSL ES to HLSL.

220 13.3DinaWebBrowser

Figure 13.10. Secure access to the GPU as a separate process [28].

Access to the GPU in the Chrome browser is provided through a protection

mechanism (see Figure 13.10) that is mandatory in order to provide the level of

security that is required by a web browser running plug-in code. The GPU is iso-

lated in its own process. The web browser is using separate render processes that

do not talk directly to the GPU, but instead run an OpenGL ES driver that con-

verts each command into a tokens in a command list (or display list) that is then

used by the GPU process on the other end. A similar architecture is used in Na-

tive Client.

Although Google Native Client technology is not ready for prime time at the

time of this writing, it is definitely one to keep an eye on for the development of

3D games for the web in the near future.

13.73DwithHTML5

The last technology we look at can be categorized at the other end of the spec-

trum relative to all the technologies we have seen so far. The idea is to provide

3D acceleration through an embedded JavaScript API in web browsers. It is simi-

lar to the OpenGL for Java bindings technology we saw earlier, but done by a

RenderProcess

WebKit

SharedMemory GPUProcess

Interprocess

Communication

Buffers

WebGL

Implementation

Desktop GL

ANGLE

Textures

SET_VIEWPORT

BIND_BUFFER

...

CLEAR

DRAW_ELEMENTS

GLES2 Client

Library

GLES2 Service

Library

13.73DwithHTML5 221

group of developers representing many browser vendors so that it is embedded

within the web browser and provides OpenGL ES 2.0 functionality that can be

called directly from JavaScript.

JavaScript is very popular for scripting on the client, although not so long

ago, the preference was to write as much as possible of a web app in the server to

avoid malicious code running in the browser or annoying pop-ups and other

anomalies. The rule of thumb was to turn off JavaScript in the browser by default

and use it only for trusted websites. This has changed as security has improved in

the browser implementation of JavaScript and with advanced user interfaces that

AJAX has brought to the user by leveraging the power of JavaScript to partially

update HTML pages without a full reload from the server at each event.

Performance has been the main concern of JavaScript applications (see Fig-

ure 13.11). Recently, the JIT technology that was developed and refined by Java

was taken advantage of by JavaScript as well as Flash ActionScript (AS3 2006)

to improve performance. In fact, JavaScript is now approaching the performance

of Java in most cases. The remaining problem with JavaScript is the large dis-

crepancy in performance (by a factor of ten in some cases) among the various

implementations that a given hardware configuration may be running. It is al-

ready difficult to target the web since there are so many hardware platforms and

performance profiles, but when multiplied by the factor of ten in the JavaScript

performance spread, this becomes an impossible problem. On the other hand,

Figure 13.11. AS3 versus JavaScript (JS) performance test (Data from http://www.

JacksonDunstan.com/articles/618, March 2010).

500

1000

1500

2000

2500

3000

3500

4000

4500

JS(Firefox3.5.2)

JS(Firefox3.6.0)

JS(IE7.0.5730.13)

JS(IE8.0.6001)

JS(Chrome2.0.172.39)

JS(Chrome3.0.195.38)

JS(Chrome4.0.249.89)

JS(Safari4.0.2)

JS(Opera9.64)

JS(Opera10.0)

JS(Opera10.5)

AS3(Flash10.0.22.87)

Total time (smaller is better)

222 13.3DinaWebBrowser

even if not the fastest in all cases, Flash provides consistent and good perfor-

mance, regardless of which browser it is running inside. A given plug-in can im-

pose the browser to update the Flash plug-in to the AS3 version if needed, but

there is no such thing for native JavaScript because the entire browser would

have to be upgraded.

So equipped with a fast scripting language and a strong desire to add hard-

ware-accelerated 3D for web application developers, Google, Apple, Mozilla,

and Opera announced during Siggraph 2009 that they would create the WebGL

working group under the intellectual property (IP) protection umbrella of the

Khronos Group [17] and joined the many working groups already working on

graphics standards, such as OpenGL, OpenCL, and COLLADA. When Vladimir

Vukićević (Mozilla) was thinking about where to create the new standard work-

ing group he basically had two choices: the W3C, home of all web standards, and

Khronos, home of the graphics standards. Since his group was composed of web

browser specialists, he thought they should join the standard body, where they

could meet with graphic specialists, because expertise in both areas is required to

create this new standard. This also enables complementary standards to be used

conjointly and solve a bigger piece of the puzzle, such as how COLLADA and

WebGL can be used together to bring content to the web [18].

Technically speaking, WebGL is an extension to the HTML

canvas element

(as defined by the W3C’s WHATWG HTML5 specification), being specified and

standardized by the Khronos Group. The HTML

canvas element represents an

element on the page into which images can be rendered using a programmatic

interface. The only interface currently standardized by the W3C is the

Can-

vasRenderingContext2D

. The Khronos WebGL specification describes another

interface,

WebGLRenderingContext, which faithfully exposes OpenGL ES 2.0

functionalities. WebGL brings OpenGL ES 2.0 to the web by providing a 3D

drawing context to the familiar HTML5

canvas element through JavaScript ob-

jects that offer the same level of functionality.

This effort proved very popular, and a public mailing list was established to

keep up general communication with the working group, working under strict IP

protection, which was quite a new way of functioning for the Khronos Group.

Even though the specification has not yet been released, several implementations

are already available for the more adventurous web programmers, and at Sig-

graph 2010, a dozen applications and frameworks were already available for

demonstration. This is quite an impressive community involvement effort, indi-

cating the large interest in having 3D acceleration without the need for a plug-in.

After the demonstration, “finally” was whispered in the audience, since some

13.73DwithHTML5 223

have been waiting for this since the first HTML demo was made almost two dec-

ades ago.

The inclusion of native 3D rendering capabilities inside web browsers, as

witnessed by the interest and participation in the Khronos Group’s WebGL work-

ing group, aims at simplifying the development of 3D for the web. It does this by

eliminating the need to create a 3D web plug-in and requiring a nontrivial user

download with manual installation before any 3D content can be viewed by the

user.

When creating a 3D game for the web, graphics is fundamental but is only a

subset of the full application. Other features are to be provided by various

nongraphics technologies that together form the HTML5 set of technologies that

web browsers are implementing (see Figure 13.12). In order to bring data into the

web browser, the game application will have to either embed the content in the

HTML page or use the

XMLHttpRequest API to fetch content through the web

browser. Unfortunately, the programmer will also have to obey the built-in secu-

rity rules, which in this case restricts access to content only from the same server

from which the HTML page containing the JavaScript code was obtained. A pos-

sible workaround then needs to be implemented on the server in order to request

external content, possibly through a simple script that relays the request.

One major issue with JavaScript is the fact that the entire source code of the

application is downloaded to the browsers. There are utilities to obfuscate the

code, which make it impossible to debug as well, but it is not too hard to reverse

engineer. This may not be the ideal, however, since game developers are not nec-

essarily happy to expose their source code.

Figure 13.12. Vladimir Vukićević (Mozilla) presents how WebGL sits in the context of

the HTML5 suite of standards at the Siggraph 2010 WebGL BOF.

IndexDB

Audio

Fonts

Workers

...

Oﬄine

WebGL

File

SVG

Canvas

Sockets

Video

Geo

CSS

XHR

WebGLInContext

SIGGRAPH2010

29JULY2010

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for 13. 3D in a Web Browser (5/6)

Create new playlist

Sign In

Sign Up

Table of Contents for
13. 3D in a Web Browser (5/6)