Thanks for your comments,
Andreas Kraft wrote:
>
> Richard,
>
> On Tue, 3 Feb 1998, Richard Houldsworth wrote:
>
> > 1. When exactly is the context change said to occur? I assume it
> > is the point after destruction of a group and before preparation
> > of another group. However, I can't find a definition anywhere.
> > Perhaps a new entry in section 3, Terms and Definitions?
>
> Good point. Can you provide us with some text?
OK, here's an attempt:
3.10 context change
The point of transition between one group object completing its
destruction behaviour and another group beginning its preparation
behaviour. At a context change all pending events and elementary
actions are discarded.
BTW, "context change" and "context switch" seem to be used
interchangeably. Perhaps standardising on "context change" across
the document would be a good idea.
> > 2. Why do asynchronous events after the context change get cleared
> > after the elementary action, and not those before? This makes the
> > MHEG event handling more complex, and I can't see what good it does.
> > Wouldn't simply flushing the event queue be simpler and more
> > predictable?
>
> I do not quite understand your point. The events are must be cleared
> after the context change (the execution of the action) because the
> action might fail and then the old scene is still valid.
Section 53.3 says:
"If such a [context-changing] action occurs, the pending asynchronous
events whose origin is after the context switch shall be removed
from the asynchronous event queue."
My point was that events enqueued *after* the event causing the context
switch but *before* the context switch actually happens will remain on
the queue. I don't think this was the original intention. A suggested
replacement wording could be:
"If such an action occurs and completes successfully then all pending
asynchronous events and ElementaryActions are removed from their
respective queues."
>
> > 3. By section 53.3 para 4, synchronous events generated in the
> > destruction phase of context changing operations are not processed
> > until after the new group has been activated. This means that
> > IsStopped and IsDeleted events can never trigger links in their
> > own scene (all links are deactivated by this point), but they might
>
> Right.
>
> > inadvertantly trigger links in the target scene for completely
> > different objects.
>
> Some might, but the "IsStopped" events don't because the targets are not
> valid anymore (with the exception that you have a general Link object
> which triggers on every "IsStopped" event...).
Some (bad) engine implementations might de-reference objects purely on
the
object number if the group name is not encoded. An object with the
same number in the new scene might receive the wrong IsStopped event.
I know I'm being a bit pedantic here, but I don't think that any sort of
behaviour should hang over from one scene to another.
> > This seems broken to me. Wouldn't it be better to
> > process any pending synchronous events before preparation of the
> > new group?
>
> Hmmm, I don't know. The problem is that this is now the behaviour and
> changing this might have great impact on existing applications.
OK, changing the point of execution of synchronous events probably is
too serious a change now, but what about specifying that pending
synchronous events are cleared at the context change? Would this impact
on existing applications at all?
>
> > 4. What use is the IsDeleted event?
<snipped: use of Unload action>
Of course. I should have seen that.
> > 5. We could avoid some of these problems by establishing action lists
> > at synchronous event *generation* not at processing. I mean that the
> > Links to fire on a synchronous event are evaluated as the event occurs.
> > Links that would be deactivated during the action would still be
> > fired. This is probably a common implementation optimisation anyway,
> > as it removes the need for a short-lived synchronous event queue, but
> > it seems to contradict 53.3 paragraph 4.
>
> As I mentioned above, changing the event mechanism is a major change to
> the standard. We should avoid this.
Fair enough. The suggestion above does show, however, that an
engine with a slightly non-conformant event processing system would
differ markedly in behaviour during context changes. I'm not saying
that the event mechanism should be changed, but rather that it could
be made more robust.
Cheers,
Richard
-- ----------------------------------------------------------------- Richard Houldsworth, Software Engineer, Philips Research Laboratories, Redhill, Daytime phone number: +44 (0)1293 815052 RH1 5HA E-mail: richardh@prl.research.philips.com