• From: "Len Bullard" <cbullard@h...>
• To: "'Rick Marshall'" <rjm@z...>, "'Robert Koberg'" <rob@k...>
• Date: Wed, 28 Feb 2007 22:38:26 -0600

These really are different conversations, Rob.   The user satisfaction for
running a real-time 3D client and loading an html page metaphor apps are
very different beasties.   In 3D, low frame rates and inconsistency of
presentation in the MU mode are simply not acceptable.  The gamers get this.
The page chunkers don't.

Maybe not orthogonal to the *best*, but it can be shown that the AJAX
architecture is not a red hot performer.  One benchmark given on the VRML
list by a developer shows an approximate 100 to 1 slowdown when using
Javascript vs Java.  I won't quote the details but he was testing with a 2D
matrix inverse routine and the VM on a 2.33 Mac.  Quoting, "Javascript is  
71x slower than (1.4% as fast as) Java -client, or 158x slower than  
(0.6% as fast as) Java -server".  On the other hand, optimizations in the
overall system can improve the Javascript performance.  The 3D apps are
tricky to get right.  I can easily show you where three different browsers
running identical VRML97 have dramatically different frame rates because the
different implementers weren't equally skilled at optimizations such as
internal culling.  Take the BS Contact client and compare it to the
competitors given a reasonably complex textured world and there is really no
comparison: the BS Contact client wins hands down even with that irritating
floating logo (they don't exactly give it away).

Wrapping real-time 3D inside HTML is not a smart move if all you really care
about is going on in the 3D display system.  It is better to move the
networking inside the client for many reasons, performance being just one.
It isn't the XML that is so punishing.  If I understand what the 3D vendors
are saying, it is the interpreted code, the overhead of marshalling in mixed
language code, faulty queueing with dropped calls, truncating of values, and
so on.  It is easy to test in real-time 3D: use the 3D browser function to
check the frame rate in various configurations.  When running in the HTML
browser, it drops dramatically.

As I said last month, HTML is a market pig.  Developers are starting to come
out of the "We are the Web and the Web is HTML" fog finally and exploring
other options where the Internet plumbing becomes just that, and the URI
architecture remains useful.  REST?  VRML was always REST.   It is a late
adopter of anything resembling XML Web Services.  Now there are reasons to
use aspects of that, but I hope the X3D/VRML guys as late adopters will be
able to pick up some lessons learned because they have many other more
serious problems.  

In real-time MU, the update latency of the web is bad juju.  There are
techniques for dealing with that but approximation/dead reckoning is the
main one.  Fortunately, schema validation and business rules verification
are not a big problem although physics is.  I am told ODE is good enough for
things until you start trying to do deformable body collisions, and the
physics models even with ODE are pretty common equations with
well-documented solutions.

A real-time virtual world metaphor and a page metaphor don't have a lot in
common.  It is worth understanding the differences.

len


From: Rick Marshall [mailto:rjm@z...] 
 
Different conversation...

Management wants the applications to look good and be buzzword 
compliant. Users (ie ordinary people in the office) - they just want an 
easy way to do their jobs. And they seem indifferent to many aspects of 
look and feel that we spend sleepless nights worrying about.

So at least part of the reason we use XML is because the clients have 
read about it and want it. Can't sell a system without it. This is 
orthogonal to the best way to do things.

Rick

• References:
  • Re: Speed in Languages and Browser Architectures
    • From: Rick Marshall <rjm@z...>