Re: [mediacapture-region] What makes CropTarget special to require an asynchronous creation? (#17)

> > As a side-comment: I don't know how you can credibly argue about performance and add 4 milliseconds of delay for no reason whatsoever. Check out [postMessage is ~100 times more frequent than setTimeout(0)](http://jsfiddle.net/jib1/y1e4rg0d/).
> 
> The token can be posted while the user is interacting with getDisplayMedia's dialog. Or even before getDisplayMedia is called. Any latency introduced by minting OR posting a token therefore becomes **zero**. 

@eladalon1983 I'm sorry are you still arguing for `setTimeout`? Do you understand its purpose is specifically to induce delay? If you meant to simply not wait for completion, just remove the `await` instead (but let's move this idea to #19):
```js
  function totallySyncFunction() {
    getCropTargetAndSendItToCapturer(element).then(() => {});
  }
```

Back to performance. I've shown a sync minting API in JS is [actually faster](https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1132232768) because otherwise [you're essentially serializing the two steps of generating the key and postMessaging it](https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1130846621). This seems to undermine your hypothesis that your design is faster. Do you disagree?

@yoavweiss's response suggests your design only [eliminates the “token hasn’t yet arrived” case, eliminating the need for timeouts and lengthy failures in case an invalid token is used by VC](https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1131846988). So your design sacrifices optimal success path of `cropTo` in order to optimize for its failure path? Am I missing something?

And in your response here you're finally claiming performance doesn't matter? Color me confused. Or are you criticizing my measurement fiddle for not demonstrating *when* the performance I measure would matter? If so, it's true I struggled to imagine an example when this would matter, but that would seem to be on you to produce. You've mentioned multiple targets... please show how the shape of `produceCropTarget` would have any bearing in that case. It would presumably have to start with IPC from a decision point, just like my measurement fiddle (which only starts measuring _post_-gDM success btw), and presumably open to the same criticisms that decisions could have started even earlier. Let's see it.

> > The misguided make-everything-async-there's-no-downside crowd don't seem to understand this or care, that the logical end of what they're advocating (await everything!¹) quickly degrades JS into this preemptive (co-routine) language again. I'm sure they would try to invent locks in JS to solve it. Thankfully, these views are more rare these days than they were in 2011, which is why I had to go back that far for sourcing.
> 
> Nobody here has ever advocated for making **everything** async, or re-inventing locks. Let's stick to the arguments presented.

You seem to be in the "no-downside crowd", claiming [there's no downsides](https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1132690689) in the face of me clearly explaining them (having to reevaluate state assumptions, fueling the proliferation of unnecessary async, non-idiomatic JS confusing web devs into thinking the API does more than it does, and finally, performance).

Let me blow up my footnote that spelled out the relevant point it seems you flat-out missed:

1. I'm contrasting extremes to aid explanation here. Clearly one more async method isn't the problem, nor does the problem only arise at the extreme. But my aim here was to clarify why the design rules we have matter, and mustn't be violated except for reasons we can all agree are sufficient.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-region/issues/17#issuecomment-1134774729 using your GitHub account


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

Received on Monday, 23 May 2022 14:49:38 UTC