<div dir="auto">I couldn’t read all of this, but I recall keeping a counter of “children loaded”. When I reached the number of children = counter, I would exit loading.  The thing was, I would often hang on the last child.  I do not recall how I solved this.</div><div dir="auto"><br></div><div dir="auto">I can probably dig into this.  I don’t recall adding extra state to nodes, rather I used a local variable, possibly passed as a parameter. I recall the number of callback functions as horrendous, so doing something with await async would probably be preferred?  Idk, sorry.</div><div dir="auto"><br></div><div dir="auto">I get the heebee jeebees just thinking about it.</div><div dir="auto"><br></div><div dir="auto">I think your containerFieldIndex may be a good idea, but I worry about missing or removed indexes.</div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 1, 2022 at 8:48 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Please let me outline an idea which would help with concurrent and<br>
asynchronous processing by making the position of a node in an MFNode<br>
array explicit. A new attribute similar to "containerField" would hold<br>
the index of the node in the array, a "containerFieldIndex" attribute.<br>
This would probably only apply to MFNode fields, and allow a browser<br>
to easily assign the intended array position to a node, even if its<br>
loading and processing is delayed, and thus support parallel and out<br>
of sequence processing better.<br>
<br>
Feel free to skip the longer explanation below, Any feedback welcome.<br>
<br>
X3D relies on the idea of sequential processing of a file. For<br>
example, USE nodes can only occur after their DEFinitions, or<br>
ProtoInstances can only occur after the corresponding<br>
ProtoDeclarations.<br>
<br>
This helps with processing since the browser can assume a sensible<br>
sequence in the file, or complain otherwise to the author. It also<br>
helps with authoring since it provides a clear paradigm an author can<br>
understand and follow.<br>
<br>
However, for nodes using remote resources sequential processing can<br>
lead to complete blocking while waiting for timeouts, or due to slow<br>
or unreliable server responses. Also, some nodes which use a lot of<br>
data, eg. large IFS, may take significant time to parse and add to the<br>
scene. In other words, for fast loading of large scenes it is<br>
desirable to process nodes in parallel and out of order or<br>
asynchronously.<br>
<br>
This is possible even with a sequential loading paradigm, the browser<br>
just has to carefully keep track of things, use placeholders etc. In<br>
fact, x3dom loads Inline and ExternProtos asynchronously, adding<br>
content and instances out of sequence to an already running scene.<br>
This way a user can start to see and interact with a scene earlier.<br>
<br>
To do this, x3dom uses the "containerFieldIndex" idea internally, to<br>
first synchronously record the index position of an ExternProto<br>
instance during sequential loading. Then, after out of sequence, slow<br>
downloading and processing, the instance is added to the parent MFNode<br>
field in the standard manner, eg. at the end of the array. But in a<br>
final step, x3dom can use the recorded containerFieldIndex to<br>
rearrange the array to have the correct order.<br>
<br>
While this can be done internally, exposing a "containerFieldIndex"<br>
attribute would have benefits. It would help authors to be both clear<br>
and flexible about how they want nodes ordered, especially when<br>
programmatically constructing scenes. It helps browsers since they<br>
could rely on such an attribute in their processing. It would be<br>
universal and apply to MFNode fields of any node. And it would promote<br>
parallel processing since nodes become more self-describing. For<br>
backwards compatibility, the default value of a containedFieldIndex<br>
attribute would be the index of the node as given by its position in<br>
the file.<br>
<br>
"containerField" is already a strange concept (since it is unusual to<br>
refer to something in parents), so "containerFieldIndex" may be even<br>
stranger. But I could not think of a better idea to help with<br>
asynchronous loading. I am pretty sure there are better ones.<br>
<br>
Thanks for reading to the end ! Cheers, Andreas<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div>