-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Canvas context type for WebGPU #6804
Conversation
@Juanmihd FYI |
@toji did you intentionally mark this as WIP? You'll need to make your membership of the googlers GitHub organization public for the Participation check. |
I did mark it as WIP intentionally to underscore the fact that we want to discuss the My organization memberships are public, but I don't seem to be in the Googlers org for some reason? I thought I was. I'll look into that. [UPDATE: Org joined. 馃槃] [UPDATE to UPDATE: ...and made public.] |
I see you've joined the org, but your membership is still not public (you can check by viewing in private browsing mode) :). I'll join the discussion in gpuweb/gpuweb#131 for the naming question. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spec text LGTM with nits
Thanks for the feedback! Updated the PR with the fixes. |
Thank you all for the feedback we received on gpuweb/gpuweb#131! As a result we've updated the context type and interface names used to take into account some of the concerns that were raised. Due to potential confusion around the term "present" or "presentation" we've dropped that verb and now define The functionality exposed by this interface has not changed, and it still functions as a way of returning drawing surfaces to the developer rather than the API which performs the drawing. This pull request has been updated to reflect those changes, and as a result has been taken out of Draft mode. Please take a look and let us know if any further updates are required! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM; thanks for the great PR!
Discussion: Define WebGPURenderingContext contextType DomString聽gpuweb/gpuweb#131
(See WHATWG Working Mode: Changes for more details.)
Posting this as a PR so that the proposed changes can be reviewed, but before landing the WebGPU working group would like to discuss the proposed context type string,
"gpupresent"
, with this group. The name differs somewhat from other context types and we want to ensure that it fits the desired patterns for these strings (if there is any) and that the name is appropriately suggestive of it's function. See gpuweb/gpuweb#131 for prior discussion within the WebGPU working group on the topic.As a brief overview: As opposed to the WebGL contexts, the
"gpupresent"
context type (which would return aGPUPresentationContext
object) is not the primary interface for interacting with the GPU hardware in WebGPU API. That's the responsibility of theGPUDevice
which is created from aGPUAdapter
enumerated by thenavigator
interface. This is to accommodate non-visual uses of the API (making use of GPU hardware for compute capabilites, for example) and also to allow a single device to draw to multiple canvas elements.As a result, the
"gpupresent"
canvas context primarily provides an surface forGPUDevice
to draw to. Because of this the WebGPU working group generally wants to avoid names like"webgpu"
,"gpu"
, or anything that could be mistaken as returning the primary WebGPU interface used for rendering."bitmaprenderer"
has a somewhat similar function to the"gpupresent"
context, in that it only displays images provided to it rather than producing the images itself. It's possible that a context named"gpurenderer"
could imply that the context was used to produce (render) the image, however, so the term "present" is preferred here as being less ambiguous.A final point of discussion within the WebGPU group is whether or not the context names should be considered analogous enums, and thus prefer using hyphenation? (ie:
"gpu-present"
) It seems that"bitmaprenderer"
has already established a precedent for not hyphenating, which is why"gpupresent"
was chosen, but we are happy to help establish a new precedent going forward if this group would prefer.馃挜 Error: Wattsi server error 馃挜
PR Preview failed to build. (Last tried on Jul 14, 2021, 7:04 PM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
馃毃 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.
馃敆 Related URL
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.