[x3d-public] LoadSensor completion of loading - extended discussion
Andreas Plesch
andreasplesch at gmail.com
Thu Dec 22 20:33:21 PST 2022
Hi Christoph,
Thank you for your reply. My initial motivation was related to event
routing from and to inner content, in the case that all nodes are
exported..
For external access to inner content it seemed necessary to have a
notification that inner nodes are available for modification. Such
nodes will need to be exported.
Perhaps the EXPORT mechanism already ensures that a node is actually
loaded, eg. cannot be a target for routes or scripts before it is
available. Let's see.
https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/networking.html#IMPORTStatement
does state:
"The IMPORT statement has the following semantics:
d. Once imported, events may be routed to or from the imported node in
exactly the same manner as any node defined with DEF."
This implies that routes are not active before a node is imported.
This achieves safe routing to loaded nodes. I think direct output to
imported nodes from scripts is also meant to be covered by this
clause.
I think what it means for LoadSensor is that if the isLoaded event is
used as the starting event for routes to loaded nodes, for example for
some initial setup, it should also only be generated after all nodes
are imported. This typically would be after recursive download of all
nested content although not necessarily, for example if no nodes are
exported from inner content.
Rendering consistency with the isLoaded event is also important. I
think authors would appreciate a guarantee that isLoaded means that an
Inline is fully rendered or will be in the next frame. This would
enable a loading screen, for example.
Another question is what would be the use case for generating isLoaded
early, eg. before recursive loading of all nested content ? I cannot
really think of a good example.
Andreas
On Wed, Dec 21, 2022 at 5:02 PM Christoph Valentin
<christoph.valentin at gmx.at> wrote:
>
> Hi Andreas,
>
> May I try to sketch the problem again, from my perspective?
>
> We try to achieve a better control by the author, whether the LoadSensor will wait for subsequent level inlines or just for the next level inlines. Hence you requested more strict rules from the X3D standard.
>
> 1) First question: shall the LoadSensor work recursive or not - that was your original question
>
> Discussion: if the LoadSensor supervises only the next level of inlines,
> then the scene that contains the LoadSensor does not "know",
> if the subsequent levels of inlines have actually been loaded
> or not.
> I see two implications: a) rendering b) event routing
> a) Rendering: here the parent scene should have control over next level
> and all subsequent levels (that's my gut feeling, nothing more)
> b) Event Routing: imho, this is a topic to be solved "level by level".
> I.e. the parent level accesses the next level, but the
> next level has to decide, whether the subsequent level(s)
> can be accessed or not (even by the parent level)
>
> 2) First conclusion: there is no general answer, whether recursive action is good or bad,
> hence the author should have some control
>
> 3) Second conclusion: Regarding Event Routing, the next level should decide, whether the
> subsequent level(s) are accessible and shall be accessed (by the
> next level or by the parent level).
>
> 4) First Suggestion: This could be achieved by a field "SFBool forwardIsLoaded"
> in the next level LoadSensor.
> When this field is set to TRUE, then all parent level LoadSensors
> would accept the next level inline only as loaded, if all LoadSensors
> in the next level inline (that have this flag set) have already issued
> the "isLoaded" event
> 5) Second Suggestion: The field "SFBool forwardIsActive" could be superseded by a field
> "SFBool recursive" in the parent level LoadSensor.
> This is equivalent to having set the "forwardIsLoaded" field in all
> next level and subsequent LoadSensors
>
> KR,
> Christoph
>
>
> Gesendet: Mittwoch, 21. Dezember 2022 um 21:26 Uhr
> Von: "Andreas Plesch" <andreasplesch at gmail.com>
> An: "Christoph Valentin" <christoph.valentin at gmx.at>
> Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org>
> Betreff: Re: [x3d-public] LoadSensor completion of loading
> Hi Christoph,
>
> I think the idea could be sketched as:
>
> <Scene>
> <Inline Outer/>
> <IMPORT LSForInner />
> Do something after LSForInner fires
> ..
>
> Inline Outer:
> <Scene>
> <LoadSensor DEF="LSForInner">
> <Inline Inner/>
> </>
> <EXPORT LSForInner/>
> ..
>
> That flexibility would favor the option to generate the event before
> downloading of inner content. The potential downside is that it
> assumes that the outer Inline has such an exported LoadSensor which
> may not be the case or even be under the author's control. Also, for
> more complex scenes it can become a lot of logic for the author to
> deal with.
>
> In any case, to avoid surprises with that option it would be even more
> important to point out in the spec. when the isLoaded event is
> generated, eg. that nested LoadSensors may be needed.
>
> -Andreas
>
> On Wed, Dec 21, 2022 at 2:42 PM Christoph Valentin
> <christoph.valentin at gmx.at> wrote:
> >
> > Hi Andreas,
> >
> > Just one neuron firing now: what about leaving the decision to the author?
> >
> > Somehow "nesting" the LoadSensor. One LoadSensor in the scene, reporting about the inline. Another LoadSensor in the inline, reporting about the second level inline. And so on.
> >
> > --
> > Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
> > Am 21.12.22, 17:51 schrieb Andreas Plesch <andreasplesch at gmail.com>:
> >>
> >> It is useful to be notified after an Inline has completed loading.
> >> This is especially true for external access to the scene if the Inline
> >> has exports (or dom style access is used).
> >> A LoadSensor generates such an event:
> >>
> >> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/networking.html#LoadSensor
> >>
> >> "The isLoaded field generates events when loading of the LoadSensor's
> >> children has completed."
> >>
> >> However, in the case that the Inline contains another Inline itself a
> >> question came up. Is loading considered complete when the outer Inline
> >> xml/json/.. is completely downloaded but still has only a url
> >> reference to the inner Inline ? That typically would happen before
> >> also the inner Inline is completely downloaded. Or should the event be
> >> generated only after the inner Inline (and all of its content) is also
> >> completely downloaded ?
> >>
> >> The second option is more useful, especially for web use where loading
> >> generally occurs asynchronously and such events are often used to
> >> initiate processing of downloaded content.
> >>
> >> For generic X3D use, one could imagine a situation where a LoadSensor
> >> triggers something which assumes that the scene is fully rendered
> >> before an Inline is actually rendered.
> >>
> >> It is also related to how EXPORT/IMPORT works. One could probably
> >> construct a situation where a LoadSensor triggers access to an
> >> EXPORTed node from an inner Inline before it is available.
> >>
> >> Is a tightening of the language necessary ? Perhaps there is already a
> >> more precise definition of 'loading' in the spec. somewhere else ?
> >>
> >> -Andreas
> >> --
> >> Andreas Plesch
> >> Waltham, MA 02453
> >>
> >> _______________________________________________
> >> x3d-public mailing list
> >> x3d-public at web3d.org
> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org[http://web3d.org/mailman/listinfo/x3d-public_web3d.org]
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
--
Andreas Plesch
Waltham, MA 02453
More information about the x3d-public
mailing list