300874 - Native X3D XML support

Status: RESOLVED WONTFIX

(Core Graveyard :: GFX, enhancement)

Description

[Ken Harris]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Galeon/1.3.21 (Debian package 1.3.21-6)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Galeon/1.3.21 (Debian package 1.3.21-6)

Mozilla currently supports 3D only through plugins.  X3D (the successor to VRML)
has an XML format, which means that native support in the browser would open up
a lot of very interesting possibilities.  (For example, see the Mozilla SVG page
for a list of some advantages of Mozilla's native SVG support, as opposed to a
plugin.)

The possibility of writing Javascript code to build and manipulate
(hardware-accelerated) 3D views of data in a web browser using the DOM, all on
the client side, makes me all tingly.

Reproducible: Always




Bug 57067 (VRML support) was closed "WONTFIX", because it "is about VRML, which
is *not* XML based" (which is true).  Also, 2.5+ years ago when it was closed,
the XML format for X3D wasn't finished (also true: the final draft is dated
2005-02-11).

Yes, this could be a "huge task".  (I don't think it would require writing an
entire OpenGL front-end for Mozilla, but I haven't really investigated.)  But
what possibilities...

Comment 1

[Ng Ming Hong]

I guess the product should be "Core" instead of "Mozilla Application Suite"?

Comment 2

[Andrew Schultz]

dumping in GFX

Comment 3

[Ian Macfarlane]

Will Cairo make this easier? Surely we wouldn't have to write an OpenGL front end if Cairo supplies one?

Comment 4

[Gordon P. Hemsley [:GPHemsley]]

This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX.

[Mass-change filter: graveyard-wontfix-2014-09-24]