(Migrated from #489) Expose limits on the adapter #495
Conversation
There's no reason to leave this out anymore. Implementations can implement it whenever they want.
|
Thanks for taking care of re-opening this. As far as I know, this is the only way to do it. |
|
To answer the question from the minutes (which I'm just reading), JG/CW are right, you can't use a dictionary type as an attribute. This is because dictionary is a WebIDL construct instructing the browser how to convert an |
|
Related: https://github.com/orgs/gpuweb/projects/1#card-29251103 We have some ideas for how to do this. We can discuss them on the coming call. |
|
Can we have a function instead of an attribute in order to avoid raw |
|
What if we made it an interface? We should be able to then use that Limits interface as an attribute, right? |
|
Jeff: that would work.
Dzmitry: I'm not sure. I think philosophically that should not work -
dictionary is an input not an output. Also, we shouldn't change the API
just to make it slightly more expressible by WebIDL. I don't see any value
in that.
…On Mon, Nov 18, 2019, 10:10 PM Jeff Gilbert ***@***.***> wrote:
What if we made it an interface? We should be able to then use that Limits
interface as an attribute, right?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#495?email_source=notifications&email_token=AAEUBE6KIVDXFVTZSRRKNVTQUMADNA5CNFSM4JL3MBV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEL5MBQ#issuecomment-555210246>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEUBEYVT2LTYAGTHY75FYTQUMADNANCNFSM4JL3MBVQ>
.
|
We already did that for many other things, e.g. enum values as strings. I don't think it's a large change to go from an attribute to a getter function - we used the latter for |
|
I don't think that's accurate. The string enums were chosen because it is "the web way" - a pattern adopted across many userspace JS libraries and Web Platform APIs. To clarify, my argument is against both proposed changes (Jeff's and Dzmitry's). In this case we would be changing the API solely for the purpose of expressibility in WebIDL (though, as I said, I suspect Dzmitry's proposal isn't expressible in WebIDL anyway). It wouldn't be because a JS library author would choose to do it that way. (To JS, Jeff's change is equivalent to changing from returning a raw dictionary to returning an instance of a predefined class, which I can imagine a library going either way on.) |
|
While that's true, interfaces are duck-type-equivalent to dicts for normal usage. I choose not to pick this battle with upstream webidl, and instead use an interface. The wording of the spec text in this PR even makes it sound like it's going to return something that's |
|
That's all fair. I'd accept that option. Slightly unfortunately, it would require duplicating the list of limits, since we'll still need a dictionary for input and an interface for output. |
|
This PR is now stale. We have the TODO in the text so we don't really need to track it here. I may open a new PR about this. |
This allows apps to receive information about individual available adapter limits, which which let the UA track privacy budgeting with better granularity. See also gpuweb#489, gpuweb#495; gpuweb#1098.
This allows apps to request information about individual available adapter limits, which lets the UA track privacy budgeting with better granularity. See also gpuweb#489, gpuweb#495; gpuweb#1098.
This allows apps to request information about individual available adapter limits, which lets the UA track privacy budgeting with better granularity. See also gpuweb#489, gpuweb#495; gpuweb#1098.
This allows apps to request information about individual available adapter limits, which lets the UA track privacy budgeting with better granularity. See also gpuweb#489, gpuweb#495; gpuweb#1098.
I think it's been determined that this API shouldn't consider privacy budgeting in it's design. - UAs can still lazily-decide on GPULimits values. - UAs can still do bucketing ahead of time, or even based on queries to GPULimits members. - Apps can attempt requestDevice without checking limits, if they just want to know if their requested limits are supported. Exact IDL interface is TBD, but editorial. Needs more text to be filled out later. Also adds some other TODOs. See also #489, #495; #1098, #1100.
I don't know how to re-open a GitHub pull request after it's been reverted. Here's a new pull request which should be the same thing.
Migrated from #489
@kainino0x says: There's no reason to leave this out anymore.
Implementations can implement it whenever they want.
Preview | Diff