[mediacapture-transform] How does generator.mute change track states? (#81)

alvestrand has just created a new issue for https://github.com/w3c/mediacapture-transform:

== How does generator.mute change track states? ==
At the moment, the setting of "mute" has two levels of "queue a task":
```
Unless one has been queued already this run of the event loop, queue a task to run the following steps:
- Let settledValue be this.[[isMuted]].
- For each live track sourced by this, queue a task to set a track’s muted state to settledValue.
```
("set a track's muted state" is a defined procedure in mediacapture-main that does not queue a task, but fires an event).

The existence of "queue a task" means that the following test snippet:
```
   generator.muted = true;
   assert_true(generator.track.muted)
```
will fail. I suppose that's the price we pay for having an event fire when we change the state.

The double dispatch means that the following test snippet:

```
  generator.track.onmute = <observer code goes here>
  generator.track.onunmute = <observer code goes here>
  generator.muted = true;
  generator.muted = false;
```
will not observe any event (because at the time the first task starts executing, "settledValue" will be false, which is "no change").

Would it be simpler to remove the outer "queue a task", so that an event is always fired when you change generator.mute, and the track's muted state changes exactly the same number of times as the generator's muted state?

I don't immediately see how to implement the "Unless one has been queued already" part either, or why its existence makes for more intuitive behavior of the API; I'd suggest dropping it.


Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/81 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 28 February 2022 13:43:35 UTC