Re: [mediacapture-transform] We shouldn't require track transferability (#113)

> > For example, `stop()` and `enabled` are synchronous. Blocking the main thread to provide the same semantics while messaging across threads can have a nontrivial cost in terms of user-perceived performance. Event handlers and `mute` probably also have their own set of issues.
> 
> Can you elaborate what the actual issues are? I can understand the general idea but not the practical implications.
> 
> In particular, the source is off the main thread and all control surfaces basically need to hop to the source thread. At worse, the shim would add a slight delay by hopping to the worker thread and then to the source thread. I don't think the main thread should be blocked to emulate `stop()` or `enabled`.
> 

If you don't block the main thread for sync operations, then you don't get the same semantics as a track on the main thread.  This is to answer the claim that an API that allows the track on the main thread is a subset of one that forces the track to be transferred to the worker because it can be shimmed.
My claim is that a shim that provides the full functionality and semantics of a track on Window is more complex and has more performance issues than what an initial shim that supports async operations like applyConstraints would suggest.

Alternatively,  applications can just abandon the previously valid assumption that all tracks can be controlled from Window and use alternative, more asynchronous and more complex architectures. 

IMO, this is placing a heavy burden on Web developers for something that can be easily fixed by adding a couple of additional factory methods to the API.


-- 
GitHub Notification of comment by guidou
Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/113#issuecomment-2583802368 using your GitHub account


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

Received on Friday, 10 January 2025 19:40:26 UTC