0% found this document useful (0 votes)
125 views

HTML5 - New UI Library For Games, Chad Austin, IMVU

At GDC 2011, IMVU presented its decision to use HTML for its downloadable client's UI. These slides are annotated with the contents of our presentation.

Uploaded by

chadaustin
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
125 views

HTML5 - New UI Library For Games, Chad Austin, IMVU

At GDC 2011, IMVU presented its decision to use HTML for its downloadable client's UI. These slides are annotated with the contents of our presentation.

Uploaded by

chadaustin
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 34

At

 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  

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy