document that requestAdapter can delay too - #523
Conversation
|
(Note of course this is a chance to the design document/rationale - not the spec.) |
|
|
||
| `GPU.requestAdapter` requests an adapter from the user agent. | ||
| It returns a Promise which resolves when an adapter is ready. | ||
| The Promise may not resolve for a long time - for example, the browser |
There was a problem hiding this comment.
IDK that we need to describe why the adapter creation can be delayed: the explanation here is very graphics-centric. What if a backgrounded tab wants WebGPU just to perform computations? (I mean, it would be ok to disallow it to avoid cryptomining in the background but the explanation is still very graphics-centric.)
There was a problem hiding this comment.
I don't think these descriptions are graphic-centric. They just assume you don't want background tabs consuming a lot of system resources (compute or memory). In any case this is just part of the design doc so I don't think that's necessarily a problem.
|
Discussed in meeting.
(Decided to merge now though.) |
9a83c08 to
4df5e27
Compare
4df5e27 to
23966d5
Compare
requestAdapter should delay until it can make the best choice about what adapter to return.