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