[x3d-public] [x3d] V4.0 Open discussion/workshop on X3D HTML integration

[Andreas Plesch]

Wow, lots of good discussion and trying to understand the issues happening.

Before I may offer input to some of the discussed points, let me state that
I find myself in agreement with many of Leonard's arguments although I do
believe that it could be possible to have better backwards compatibility
(probably at a performance cost in the web browser).

Time: x3d has a good, strict time model allowing for precise simulations. I
do not believe cobweb follows that time model but I may be wrong. With some
accounting and overhead it should be possible to implement the x3d time
model but I am not sure it is that desirable.

Native, declarative 3d support in web browsers: At this point it would be a
mistake to assume that web browser will natively support any declarative 3d
scene formats in the near (or far) future. There are too many 3d solutions
based on webgl already available. Keep in mind that web browsers even
internally use their own javascript engines to implement HTML5 features in
javascript, not compiled code. These js engines are actually byte code
compilers which is pretty close to the metal. Without keeping performance
in mind, it is possible to produce slow js code. But it is also possible to
produce very performant js code if written carefully. Having said all this,
I believe the way to get into web browsers would be to follow the svg
example and define a x3d DOM and interfaces (then come up with a polyfill,
and then also come up with a proof of concept implementation in C++ in
mozilla, - a huge task which may be rejected).

webgl vs. opengl: webgl is more focused on the shader. This lets the GPU
render very fast, potentially faster than the classic opengl pipeline. I do
not believe there is any drawback using webgl only. It is all in how to get
the data to the GPU.

Render loop: cobweb and x3dom render frames independent of waiting to
changes to the scene graph to arrive at a finished state. To keep the web
browser responsive, accepted practice is to not render as fast as possible
but only as fast as necessary to have a good frame rate. This is
accomplished by letting the web browser control when a new frame in a x3d
scene needs to be rendered. So instead of a rendering loop, you will just
see a requestAnimationFrame invocation with a callback which initiates the
rendering of a new frame whenever the web browser requests it. Typically
that happens every 1/60 s I believe if not too many other things are
happening. This is a major difference between the x3d browser and the html5
web browser environment since in the web browser environment it is
necessary to coexist in a friendly manner with other elements controlled by
js scripts on the same web page.

plugin vs. js implementation: The traditional web binary plugin container
was abandoned for all kinds of content for good reasons. cobweb already
provides SAI type html integration. I do not think the spec. needs any
changes for this type of integration. cobweb only adds a html <x3d> tag
which is different from the x3d <x3d> element. It simply refers to an .x3d
file in an url attribute. This html <x3d> tag could be formalized in the
spec. DOM integration like in x3dom is very desirable, however, and is what
would be expected by web programmers.

DOM integration: While I do think that good thinking on a spec. is  very
necessary, I also think it is critical to work from existing
implementations or from building new implementation based on Xflow or
aframe. It is too easy to get carried away otherwise. My best idea at this
point is to work from cobweb but enhance it with a bridge between the x3d
graph and a new, constructed DOM graph.

Roughly, I can see that cobweb could construct a DOM graph by adding html
elements to the page while parsing the x3d xml. Then, all x3d nodes could
be registered as new html elements which allows 'life cycle' management and
lets js catch any changes to the constructed x3d DOM graph (this is what
x3dom does). Then, changes to the attributes of html elements could be
transferred to changes in the fields of the corresponding x3d nodes by SAI
methods. In turn, cobweb updates the scene. In the extreme, this means that
cobweb could start with an empty scene. It is then populated as the web
browser recognizes registered x3d elements on the web page, and the bridge
calls the appropriate SAI methods. The bridge could be pretty stupid this
way and just needs to maintain a map between the html and x3d graphs.

I may try to explain this to Holger and see if he agrees and if he would be
inclined to accept help implementing this. But this would not happen any
time soon and would slow down cobweb due to the bridging work. One could
have a non-DOM and a DOM cobweb version.

-Andreas

-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160610/f07e4ccb/attachment-0001.html>