HTML5 - New UI Library For Games, Chad Austin, IMVU
HTML5 - New UI Library For Games, Chad Austin, IMVU
GDC
2011,
on
behalf
of
IMVU
Engineering,
I
presented
our
thesis
that
HTML
is
the
new
UI
library
for
developing
desktop
applicaGons
and
games.
1
2
The
browser
wars
are
hoJer
than
ever.
We
have
four
major
browser
vendors,
each
with
significant
market
shares,
compeGng
in
earnest.
Features
such
as
SVG,
Canvas,
GPU
acceleraGon,
FAST
JavaScript
engines,
and
even
WebGL
are
widely
available.
3
It's
a
great
Gme
to
be
a
web
developer!
4
When
I
refer
to
HTML,
I'm
really
referring
to
the
enGre
stack
of
web
technologies:
markup,
style
sheets,
scripts,
canvas,
websockets,
etc.
Also,
Mozilla's
branding
is
confusing:
Firefox
the
browser
is
built
by
Mozilla
the
company
and
is
powered
by
Gecko/XULRunner
the
technology.
Internally,
we
use
these
terms
interchangeably.
5
6
In
2004,
when
the
company
was
started,
IMVU's
enGre
UI
was
wriJen
in
Win32,
OpenGL,
and
C++.
This
is
a
fairly
tradiGonal,
though
old
school,
way
to
build
UIs.
However,
our
framework
was
extremely
rigid,
and
it
was
hard
to
hire
people
to
work
on
it.
We
tell
legendary
stories
of
"I
just
wanted
to
move
that
buJon
from
here
to
there,
but
I
couldn't
figure
it
out
in
a
few
hours,
so
I
gave
up".
In
addiGon,
our
iteraGon
speeds
were
terrible.
You
had
to
recompile,
maybe
add
some
new
funcGonality
to
our
UI
framework,
and
then
restart
the
client.
This
made
UI
development
hard
enough
that
we
simply
didn't
do
it.
The
product
didn't
change
much
for
3
years.
7
In
2007,
a
couple
engineers
realized
we
had
a
problem
and
spent
a
weekend
integraGng
Adobe
Flash.
Flash
is
widely
available
and,
if
you
get
permission
from
Adobe,
you
can
distribute
Flash
with
your
applicaGon.
We
implemented
support
for
Flash
UI
panels
and
rendering
Flash
to
translucent
overlays
atop
the
3D
scene.
Using
Flash
to
develop
UI
was
definitely
a
huge
improvement.
We
used
the
Flex
UI
library
and
its
standard
components
to
get
a
head
start.
We
were
suddenly
able
to
iterate
on
our
UI,
and
we
could
add
capabiliGes
like
animaGon
and
video
to
our
client.
That
said,
Flash
wasn't
all
roses.
It
consumed
a
great
deal
of
memory,
especially
address
space,
and
mxmlc
compiles
were
sloooow.
Finally,
even
though
Flex
is
open
source,
we
found
several
bugs.
8
In
2009,
we
began
a
project
to
rebuild
our
enGre
experience
from
first
principles.
Our
very
talented
design
team
spent
months
iteraGng
with
paper
prototypes
and
user
tests,
and
produced
a
very
snazzy
client
architecture.
At
that
point,
the
engineering
team
had
some
implementaGon
choices:
1)
Should
we
build
this
UI
with
a
custom
framework?
2)
Should
we
use
our
exisGng
Flash
technology?
3)
Or
should
we
try
integraGng
a
browser
and
use
HTML?
We
decided
to
give
a
browser
a
shot,
and
we
started
with
Firefox,
since
a
couple
of
our
people
had
familiarity
with
the
Gecko
codebase.
Within
days
we
had
something
up
and
running,
and
the
performance
was
amazing!
It
loaded
quickly,
was
super-‐responsive,
and
used
hardly
any
memory.
We
instantly
decided
to
use
HTML
for
the
enGre
project.
The
UI
we
built
in
HTML
matched
the
intended
design
almost
to
the
pixel.
IteraGon
was
nearly
live:
and
we
could
even
do
our
development
in
Firefox
the
browser
with
the
Firebug
add-‐on.
9
10
We
patched
Gecko
to
support
rendering
documents
into
textures
so
that
we
could
overlay
them
on
top
of
the
3D
scene.
This
let
us
build
sophisGcated
UI
elements
across
our
enGre
product.
11
12
13
IMVU
is
a
Silicon
Valley
company,
and
we
hire
people
from
all
backgrounds.
We
don't
necessarily
hire
people
for
the
skills
they
already
have;
instead,
we
assume
they'll
be
able
to
learn
whatever
we
need.
That
said,
it's
valuable
for
people
to
have
some
background
knowledge,
and
almost
everyone
these
days
knows
a
bit
of
the
web
stack.
You
can't
expect
experGse
in
the
nuances
of
the
box
model,
but
everyone
knows
a
bit
of
HTML
and
JavaScript.
14
The
web
stack
brings
with
it
a
plethora
of
tools
like
Firebug
and
Firebug
Lite.
We
use
these
tools
every
day
to
rapidly
iterate
on
our
markup
and
style
sheets.
We
can
even
integrate
Firebug
Lite
into
our
downloadable
client
and
work
with
live
data.
15
In
the
last
few
years,
we've
seen
a
proliferaGon
of
amazing
JavaScript
libraries
such
as
jQuery
and
YUI.
If
you
build
your
UI
with
web
technologies,
you
can
leverage
these
libraries
directly.
16
When
we
integrated
web
technologies
into
our
applicaGon,
we
discovered
an
unintended
benefit.
We
could
now
directly
benefit
from
the
tens-‐of-‐billion
dollar
Internet
adverGsing
industry,
which
has
built
an
enGre
adverGsing
pipeline
around
HTML,
JavaScript,
and
Flash.
One
engineer
integrated
ads
into
our
product
in
less
than
one
week.
17
At
this
point
in
the
presentaGon,
I
gave
two
mini
demonstraGons.
First,
I
showed
what
Firebug
Lite
was
capable
of:
JavaScript
commands,
real-‐Gme
ediGng
of
aJributes
and
styles.
Then
I
demonstrated
the
process
by
which
we
iterate
on
our
UI
by,
in
5
minutes,
adding
a
jQuery
accordion
to
an
HTML
overlay
and
demonstraGng
that
the
change
had
already
taken
effect.
18
19
The
biggest
concern
we
hear
from
others
is
"Wouldn't
the
web
stack
be
slow
and
take
a
lot
of
RAM?"
There
was
a
Gme
when
browsers
were
comparaGvely
slow
and
heavy,
but
with
today's
fast
CPUs
and
the
conGnual
pressure
to
make
browsers
faster
(rich
web
experiences,
tabbed
browsing),
we've
found
that
HTML
has
never
been
a
boJleneck
for
us.
20
Gecko
consumes
less
than
1
MB
of
RAM
for
each
loaded
document,
and
we
even
think
we'd
be
able
to
make
every
seat
node
in
the
scene
into
an
HTML
overlay.
21
You
do
need
to
be
careful
with
DOM
structures
with
huge
numbers
of
children.
Many
DOM
operaGons
are
linear
in
the
number
of
children
or
siblings,
so
you'll
want
to
structure
your
DOM
with
a
b-‐tree.
22
You
also
need
to
be
careful
with
image
tag
and
canvas
memory
usage.
Avoid
allocaGng
for
elements
that
aren't
immediately
visible.
23
Flash
is
sGll
beJer
at
animaGon,
but
I
think
this
will
change.
This
may
simply
be
a
tool-‐chain
issue.
3D
on
the
web
is
possible
now,
but
WebGL
isn't
quite
prime
Gme.
This
year
we
expect
WebGL
penetraGon
to
reach
50%
of
the
market
(Chrome
and
Firefox),
but
we
sGll
depend
on
our
sooware
renderer
for
our
customers
without
strong
or
reliable
GPUs.
Tracing
JITs
are
sGll
RAM-‐hungry
and
don't
match
naGve
code
performance
yet.
Core
game
components
will
sGll
be
wriJen
in
close-‐to-‐the-‐metal
C++.
24
25
The
independent
game
studio
Wolfire
uses
WebKit
for
an
in-‐game
material
and
shader
editor.
They
used
the
off-‐the-‐shelf
editor
component,
CodeMirror,
for
their
text
editors.
26
CodeMirror
–
in-‐game
shader
and
script
editor
27
Electronic
Arts
ported
WebKit
to
PlayStaGon
3
for
Skate
3.
About
50%
of
their
UI
was
wriJen
in
HTML
and
JavaScript.
28
Neslix
on
PlayStaGon
3
uses
WebKit
so
they
can
split-‐test
their
UI
aoer
they've
shipped.
That
way
they
can
improve
their
UI
without
shipping
new
sooware.
29
Several
MMOs
have
added
browsers
so
they
can
include
forums,
wiki,
and
help
within
their
games.
30
There
are
two
base
rendering
engine
choices.
I’d
probably
start
with
WebKit
since
most
people
use
it.
31
There
are
several
open
source
and
commercial
libraries
to
help
you
get
started.
I've
included
a
list
in
the
slides
above.
32
I'd
like
to
conclude
by
saying
that
HTML
has
worked
very
well
for
us,
and
I
strongly
encourage
you
to
give
it
a
shot.
Send
me
a
message
at
chad@imvu.com
to
let
me
know
if
it
works
for
you
or
not!
33
I'd
like
to
clarify
some
points
I
made
during
the
Q&A
session:
A
man
from
Khronos
approached
me
and
said
I
was
a
bit
hard
on
WebGL.
If
I
came
across
that
way,
I
didn't
mean
it.
I
love
WebGL
and
the
work
that
Khronos
has
done,
but
I
don't
think
it's
prime
Gme
_yet_.
We
can't
port
our
exisGng
product,
which
ooen
runs
on
machines
without
a
reasonable
GPU,
to
WebGL
yet.
We
do,
however,
intend
to
write
a
WebGL
backend
eventually.
By
the
end
of
the
year,
we
expect
50%
WebGL
adopGon.
Someone
asked
about
iniGal
startup
overhead.
I
said
we
probably
consumed
30
MB
of
RAM
and
address
space
in
base
Gecko
iniGalizaGon,
but
that
we'd
done
absolutely
no
work
to
reduce
that.
On
the
console,
I
expect
it
would
be
worth
opGmizing
further.
There
was
some
discussion
around
how
our
designers
and
engineers
interacted.
I
menGoned
that
our
teams
are
ooen
cross-‐funcGonal:
our
designers
typically
know
enough
CSS
to
make
changes
if
they
want
and
some
of
our
engineers
have
strong
design
sense.
We
find
it
more
producGve
to
just
sit
down
together
and
have
an
engineer
and
a
designer
work
together
over
an
hour
to
polish
up
the
experience.
34