Robustness issues with componentchanged event due to throttling

[diarmidmackenzie]

Description:

• A-Frame Version: 1.2.0.
• Platform / Device: All
• Reproducible Code Snippet or URL: None (can create if required).

In my application, I have some state that is (for usability reasons) controlled by multiple different mechanisms. One of these is a toggle switch displayed in the VR scene.

The master record of the state is on an entity A, component C.

I want the toggle switch T (a distinct entity from A) to reflect the state of C.

To do this, T listens for the component changed event on A. When this event fires, it checks the state of component C and updates the toggle switch state.

This works well most of the time. However I have hit some issues due to throttling on componentchanged event.

There are cases where I want to reset things in my scene, and a convenient way to do this is to toggle the state of C off & on again in consecutive lines of code.

When I do this, the following happens:

• Turn C off
• componentchanged event triggers on T. T updates to reflect off state.
• Turn C on again.
• component changed event does not fire again, because it is throttled on a 200msec timer. (see:

  aframe/src/core/component.js

  Line 75 in b164623

  this.throttledEmitComponentChanged = utils.throttle(function emitChange () {

  ).
• Now T is stuck indefinitely, in an incorrect "off" state, not reflecting the master state of C.

I recognize that there are good performance reasons for throttling componentchanged events. However it seems that the consequence of this throttling is a lack of robustness in the componentchanged event, which means it can't be depended on.

My understanding is that the intent of componentchange is to provide a way for monitoring for changes on a component without having the cost of running a permanent tick to monitor it. But if component changed can't be relied on to fire when a component changes, then it seems unusable for this kind of use case, and I'll end up having to revert to monitoring on a tick...

It seems to me that a slightly more sophisticated form of throttling could solve this problem, while keeping the performance benefits of throttling:

When a component is changed within 200 msecs of a componentchanged event, rather than dropping further notifications, I suggest that A-Frame should instead set a flag indicating that a further component change has occurred, and then 200 msecs later, generate an additional componentchanged event (only one would be required, no matter how many changes there had been in the 200msec period).

I'm happy to help progress this further:

• I can create a simple glitch repro if needed.
• I'm happy to attempt to implement a fix.

Before that, though, I'd like to check whether there'd be interest in moving forward with a chage along these lines?

[dmarcos]

The recommended way to track the state more often is with a tick method in a different component as you mentioned. tick method less overhead than firing DOM events.

Don't know your use case but you might want to check the aframe-state-component

[diarmidmackenzie]

Maybe I didn't explain this well enough. I don't need to track state more often, just more reliably.

The component doesn't change state very often at all. It's just that it can (on rare occasions) flip twice within 200msecs.

Also, I don't need to respond quickly to changes (200msec lag would be fine). But I do need to respond reliably.

Given the component state changes rarely, I believe componentchanged is a better solution than a tick() monitor, as it will be more performant overall. But the issue above is causing problems.

Can you explain what use cases componentchanged is intended for? I'm struggling to see how it can ever be useful if it doesn't reliably fire following a change to a component.

I could look at aframe-state-component, but if you don't agree that a change here is warranted, I'll probably stick with my current workaround where I explicitly trigger an additional synthetic "componentchanged" event in my component's update() function. That's working fine, it just feels like it shouldn't be necessary.

[dmarcos]

componentchanged is for low frequency updates. Less than 5 times per second. Maybe we can clarify docs. In general I don't end up using componentchanged that much in my real world applications.

In the applications I wrote I usually care about the final state and not so much about the intermediate states that the throttled componentchanged event might be skipping. A solution could be inverting the logic but not sure if appropriate in your scenario. The component and entity that changes state (entity A component C in your example) modifies / call the other entity(s) component. Another solution is to emit another event (as you mentioned) youallneedtochange in your update method. This will add semantic to your events and will be more targeted vs. the more generic componentchanged that many entities might be listening to.

For the less common scenarios where I need to closely track a state. e.g: collision detection I use a tick method (that also can be throttled) to pull the state when necessary. In general, components pulling data when they need ends up with cleaner more efficient code. Events / subscription systems often end up being messy to debug and understand.

For application level state I recommend centralizing instead of scattering across multiple entities / components. aframe-state-component is a good example of that. entities subscribe to relevant changes.

About your solution:

When a component is changed within 200 msecs of a componentchanged event, rather than dropping further notifications, I suggest that A-Frame should instead set a flag indicating that a further component change has occurred, and then 200 msecs later, generate an additional componentchanged event (only one would be required, no matter how many changes there had been in the 200msec period).

I think you would potentially still miss some state transitions if more than 2 changes occur in 200ms? If you want to extend that to more than 2 you might end up spamming / broadcasting wrong info. e.g 10 changes within 200ms generate 10 events for the next 2 seconds.

[diarmidmackenzie]

In the applications I wrote I usually care about the final state and not so much about the intermediate states that the throttled componentchanged event might be skipping.

That's exactly my point. All I care about is the final state. Very happy for throttling to skip the intermediate states - that is what I am proposing the throttling should do.

But that is not what the throttling does today.

• It is not skipping the intermediate states (more precisely, it is not skipping the first intermediate state)
• It is skipping the final state. Because the final state change happens within 200msecs of an intermediate state.

I think you would potentially still miss some state transitions if more than 2 changes occur in 200ms?

Yes, agreed I would miss some state transitions. That's absolutely fine. All I care is getting an accurate final state.

[diarmidmackenzie]

Have been trying to create a glitch repro of this, and I can't reproduce the behaviour I thought I was seeing in my application. I will clarify this & post another update shortly.

[diarmidmackenzie]

Here is a glitch that demonstrates the problem. Click on the left cube. Right cube should (IMO) change color to match, but just gets stuck black instead.

https://glitch.com/edit/#!/component-change-on-throttling2?path=index.html%3A54%3A14

[dmarcos]

I see. thanks for the patience. we should probably debounce instead of throttling. That will fix your issue

There are examples in the code if you want to give it a try: https://github.com/aframevr/aframe/blob/master/src/components/cursor.js#L68

[dmarcos]

Worth checking the visualization from the stack overflow question above:

http://demo.nimius.net/debounce_throttle/

Problem is that if a component is updated at high frequency continuously the event might not be ever emitted or have a long delay.

[dmarcos]

Another option is to write a new function that combines throttling and debouncing. I found an example but not studied in detail:

http://jsfiddle.net/lebbe/eygq4m4b/

An issue of the combo I think could be duplicated events. One change triggers two componentchanged events. That case could be accounted for in the new function I think

[vincentfretin]

Hi, just following your discussion. I just wanted to mention the example of the lodash throttle function
https://lodash.com/docs/4.17.15#throttle
From their documentation: "The func is invoked with the last arguments provided to the throttled function. Subsequent calls to the throttled function return the result of the last func invocation."

The code of the throttle function
https://github.com/lodash/lodash/blob/15e1557b2a97c8bbee22d873832d90ed3ba50ba7/throttle.js
is actually a special case for the debounce function here
https://github.com/lodash/lodash/blob/15e1557b2a97c8bbee22d873832d90ed3ba50ba7/debounce.js#L188-L190
You see it keeps the lasted arguments, so when the timeout triggers, it will call the function with the latest arguments.

[diarmidmackenzie]

@dmarcos - Yes, I'm happy to look at a fix here. I may not get to this very quickly, as I have now got adequate workarounds in place for this problem, but hope to work on this over the next few weeks.

[dmarcos]

https://github.com/aframevr/aframe/pull/4980/files might fix the issue. Let me know if it does. Thanks

[dmarcos]

@diarmidmackenzie Does the PR referenced above fixes your issue? Thank you!