-
Notifications
You must be signed in to change notification settings - Fork 45
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extensibility of wgpuSurfaceGetCurrentTexture #261
Comments
Actually looking at the comment there I'm not sure if I meant "OK to make extensible" or "OK to not make extensible". I suspect I actually meant "OK to not make extensible" which is the opposite of what I thought this morning. |
Jan 25 meeting:
|
Likewise, should be have some form of both in and out extensibility for present? For example to request present timings. |
That's a good idea. Let me file that under #216. |
|
Meeting Jan 4:
Actually we already talked about making GetCurrentTexture extensible and it seems we wanted to do that.(Actually looking at the comment there I'm not sure if I meant "OK to make extensible" or "OK to not make extensible". I suspect I actually meant "OK to not make extensible" which is the opposite of what I thought this morning.)
Though writing this out, I realize making WGPUSurfaceTexture extensible isn't necessarily the same as making GetCurrentTexture extensible, since WGPUSurfaceTexture is an output structure. Nothing stops us from extending it with input components (making it a mixed-input-output structure) but the name "WGPUSurfaceTexture" doesn't make much sense in that case.
Right now we have lots of in-extensibility but only some out-extensibility: wgpuGetInstanceFeatures, wgpuAdapterGetProperties, wgpuAdapterGetLimits, wgpuDeviceGetLimits, wgpuSurfaceGetCapabilities.
None of these are mixed-input-output but they could be if we needed them to be.
(thinking about made me think of #260 ^_^)
A few options:
0a - Do not worry about extensibility now and make a GetCurrentTexture2() if we ever need it.
0b - Alternate form.
1 - Do the thing we discussed and defer a decision on whether to allow input members in the chain. (EDIT: fixed chain constness here)
2 - Explicitly make it mixed in-out. I struggle with naming in this one. (EDIT: fixed chain constness here)
3a - Split in and out and make only 'in' extensible, but notably the 'in' structs could contain out-pointers:
3b - Technically the outputs could all be in the Info struct.
There are a bunch more permutations on this (like having both an extensible-in and extensible-out struct) but you get the idea. I'm stopping here because 3a seems actually decent.
The text was updated successfully, but these errors were encountered: