proj-imim:
Java/JavaScript problems
Paul Ellis 2000-May-14 19:29:59
Hi List
I must admit I'm no Java/JavaScript expert. However, I'm starting to get the
distinct impression that attempting to make a high-quality, full-featured
viewer system using this combination is a lost cause. Reasons:
* Java and JavaScript are supposed to be standards. However, for commercial
reasons, neither Netscape or Microsoft properly implement them, but insist
on their own, proprietary, mutually-exclusive "extensions". This situation
is highly unlikely to change.
* Implementation varies across platforms.
* Implementation (and bugs) vary between different versions of the same
browser. For legacy reasons, this situation won't change, either.
* By virtue of its emulated nature, Java will always be slower than native
code.
* A Java pano cannot be guaranteed to be viewable. Because of the
possibility of hostile applets, many corporates filter out Java at the
firewall. However, I've found the same corporates usually allow Flash
through.
* On the Mac, at least, a running Java applet uses a significant amount of
processor time, causing the surrounding environment (rollovers, etc.) to
perform sluggishly, resulting in a disappointing user experience.
I'd like to propose the following:
1) Bring PTVJ to version 1.0 by optimising as far as possible the download
time in IE. Leave the feature set as it is.
2) Add high-quality bilinear rendering to the native viewers and add the
ability for the viewer to save stand-alone in multi-platform formats: i.e.
for the Mac viewer to also be able to save a Windows .exe and Windows to be
able so save a Mac application. That way, we can email stand-alone panos to
recipients in the sure knowledge that they will run properly. Adding hotspot
functionality, so that a folder-full of panos will all appear within the
same window (in much the same way as hotspotted iPIXes do) would further
increase the usefulness of the stand-alone viewer.
3) Assuming it's technically feasible, concentrate further development on
incorporation into Flash, so that complete virtual tours can be delivered
within Flash. Reasons:
* The file format is open
* It is highly pervasive, being a standard part of the install of all v4 and
later browsers
* If it's not present, it's a much smaller download than QT
* It turns the host OS and browser into a shell, avoiding platform/
version/combination problems and sidestepping Microsoft's and Netscape's
commercial agendas
* It becomes a self-contained environment including panos, navigation,
animation and other features, under our control.
* ...then develop a QT component.
I know that Helmut also wishes to develop a system whereby Java content can
be intercepted by a native component (browser plugin or whatever), therefore
making it possible to only have to author the content once, the end user
getting a higher-performance experience if they have the native component
installed. I'm very much in favour of this, but if it can also be done from
within Flash, that's one less plugin to have to download. Furthermore, the
native component approach doesn't solve our JavaScript navigation problems.
I appreciate that Flash authoring software is not currently available free,
and that Helmut clearly wishes to create a panoramic system comprised
entirely from free software. However, I would point out that apart from
GIMP, the host applications for Panorama Tools plugins are not free, either.
Any subtle image editing on Mac or Windows requires commercial software.
Therefore, I see no philosophical objection to embracing Flash.
Comments, anyone?
Paul Ellis
#removed#
http://www.mnetwork.co.uk