O'Reilly logo

OpenGL Insights by Christophe Riccio, Patrick Cozzi

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Features and Design Choices
in SpiderGL
Marco Di Benedetto, Fabio Ganovelli, and
Francesco Banterle
41.1 Introduction
Technologies related to computer graphics (CG) are constantly growing. This is
mostly due to the widespread availability of 3D acceleration hardware with an un-
precedented ratio of performance to cost. In the past, access to such accelerators was
confined to workstations; nowadays, even handheld devices such as smartphones are
equipped with powerful graphics hardware. On a parallel timeline, with the intro-
duction of OpenGL, CG software has moved to proprietary solutions from royalty-
free specifications. In addition, widespread access to broadband Internet connections
have led to a tremendous increase in content availability, as well as a great enrichment
of web technologies, such as HTML5.
In this mature scenario, the WebGL specification was introduced to allow CG
and web programmers to leverage the power of GPUs directly within web pages.
WebGL is a powerful technology based on the OpenGL ES 2.0 specification, and
it thus adheres to the philosophy of a barebones low-level API. As it happens in
similar contexts, a series of higher-level libraries have been developed to ease usage
and implement more complex constructs.
SpiderGL [Di Benedetto et al. 10] is a JavaScript CG library that uses WebGL
for real-time rendering. The library exposes a series of utilities, data structures, and
algorithms to ser ve typical graphics tasks. When developing SpiderGL, we wanted
to create a library able to simplify the most common usage pattern of WebGL, and
that could guarantee a seamless integration into complex software packages. Its role
of middleware imposed on us a need to enforce consistency whenever users wanted
583
41
584 VII Software Design
to access the underlying WebGL layer, and to provide a solid foundation for the
development of higher-level components. The library can be downloaded from the
SpiderGL website, http://spidergl.org.
In this chapter, we discuss the most important choices that we made while de-
signing and developing SpiderGL. In Section 41.2, we will briefly discuss the library
architecture. The definition of 3D objects is detailed in Section 41.3. Section 41.4
discusses the problems arising from the object-binding paradigm imposed by the API
and how we deal with it. In Section 41.5, we describe how SpiderGL wraps native
WebGL objects and how we guarantee a robust interoperability with low-level calls.
Section 41.6 draws conclusions from our work.
41.2 Library Architecture
The global philosophy of the SpiderGL librar y is to provide a procedural interface
to typical CG algorithms and data structures. With the procedural approach, it
is possible to create higher-level interfaces, i.e., scene graphs, that use SpiderGL as
a lower-level library. In designing this software, we imposed on ourselves a series
of requirements, the most important of which was to never prevent the user from
directly accessing WebGL native functionality. Guaranteeing this property means
that a seamless cooperation of high-level SpiderGL code and low-level WebGL calls
can be achieved, giving more freedom to users.
The library is composed of several modules, implemented as JavaScript name-
space objects. The top-level object, SpiderGL,servesasthemainlibraryname-
space and avoids polluting the JavaScript global object. The encapsulation of sym-
bols within modules create a clean structure but results in more verbose code. For
this reason, we provide a function that opens each module namespace, making con-
tained symbols properties of the global object and thus accessible without qualifying
them. For example, after opening namespaces, the generic object SpiderGL.Some
Module.SomeClass is aliased by SglSomeClass; this means that when adding
new symbols, we have to avoid name clashes across modules.
There are top-level modules intended to provide most of the interfaces needed
by users, and transversal modules, e.g., components whose functionalities are used
by other modules. The following is a brief description of what SpiderGL modules
contain:
Core. Basic constant definitions and the SglObject class, the base prototype
used by every object of the library.
Type. Symbolic constants that represents scalar types, i.e., SGL UINT16 and
SGL
FLOAT32, as well as functions to convert from and to WebGL-type sym-
bolic constants. Utility functions to identify JavaScript types, i.e., isArray(),
and implement prototypal inheritance are also provided.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required