Open kainino0x opened 11 months ago
- Related to: Should more functions take extensible structs? #216
- ~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.
Jan 25 meeting:
void wgpuSurfaceGetCurrentTexture(WGPUSurface, WGPUGetCurrentTextureDescriptor const *, WGPUSurfaceTexture *);
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 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.