Change GPUColor/Origin3D/Extent3D to sequences#299
Change GPUColor/Origin3D/Extent3D to sequences#299kainino0x wants to merge 1 commit intogpuweb:masterfrom
Conversation
kvark
left a comment
There was a problem hiding this comment.
I'd prefer not to go this way. Sequences involve indirection, and they have weaker type-level semantics than our structures:
- no field names
- no forced number of fields
|
Even though it's not expressed by the IDL, I'd like to express those constraints in the spec. |
|
I'd prefer the current approach for the same reasons as @kvark. I guess typed arrays could be another option instead of raw sequences. Typed arrays would probably increase verbosity, but would enforce type for values (i.e. Maybe we'll have typed objects someday :) |
|
FYI: Blocked on @jdashg's alternative proposal. |
|
Closed in favor of #319 |
|
Recently I'm again finding myself wanting to only allow sequences, for simplicity of the spec and implementation, especially with the merging of arrayLayers into depth/z. Is there any appetite to revisit this? (@kvark in particular) Specifically I would want to do this only for Origin and Extent (not color, as the order is not so obvious), and we would have extra bindings rules for sequence length. |
|
It eliminates the ambiguity for 1d-array textures: #613 (comment) |
This overload adds complexity without providing much benefit of clarity. In all contexts, the semantics of the values in an array used as a GPUOrigin/Extent are clear; depending on the context, one of: - [width] - [width, arraysize] - [width, height] - [width, height, arraysize] - [width, height, depth] In order to implement this, this redefines GPUOrigin2D, GPUOrigin3D, and GPUExtent3D from scratch, as if they were specified in the WebIDL spec. These essentially implement a specific case of tuples with default values, which could be expressed in pseudo-WebIDL as: ``` typedef [GPUIntegerCoordinate = 0, GPUIntegerCoordinate = 0] GPUOrigin2D; typedef [GPUIntegerCoordinate = 0, GPUIntegerCoordinate = 0, GPUIntegerCoordinate = 0] GPUOrigin3D; typedef [GPUIntegerCoordinate, GPUIntegerCoordinate, GPUIntegerCoordinate] GPUExtent3D; ``` I previously proposed this in gpuweb#299. After discussion, we compromised on this union, and it was implemented in gpuweb#319. However there were a number of voices who didn't like the added complexity (and perceived loss of type expressivity), and since then I've come to agree that the unioned version is not the best choice.
This overload adds complexity without providing much benefit of clarity. The semantics of the values in an array are clear according to context: - 1d: [width] - 1d-array: [width, arraysize] - 2d: [width, height] - 2d-array/cube/cube-array: [width, height, arraysize] - 3d: [width, height, depth] In order to implement this, this redefines GPUOrigin2D, GPUOrigin3D, and GPUExtent3D from scratch, as if they were specified in the WebIDL spec. These essentially implement a specific case of tuples with default values, which could be expressed in pseudo-WebIDL as: ``` typedef [GPUIntegerCoordinate = 0, GPUIntegerCoordinate = 0] GPUOrigin2D; typedef [GPUIntegerCoordinate = 0, GPUIntegerCoordinate = 0, GPUIntegerCoordinate = 0] GPUOrigin3D; typedef [GPUIntegerCoordinate, GPUIntegerCoordinate, GPUIntegerCoordinate] GPUExtent3D; ``` I previously proposed this in gpuweb#299. After discussion, we compromised on this union, and it was implemented in gpuweb#319. However there were a number of voices who didn't like the added complexity (and perceived loss of type expressivity), and since then I've come to agree that the unioned version is not the best choice.
This overload adds complexity without providing much benefit of clarity. The semantics of the values in an array are clear according to context: - 1d: [width] - 1d-array: [width, arraysize] - 2d: [width, height] - 2d-array/cube/cube-array: [width, height, arraysize] - 3d: [width, height, depth] In order to implement this, this redefines GPUOrigin2D, GPUOrigin3D, and GPUExtent3D from scratch, as if they were specified in the WebIDL spec. These essentially implement a specific case of tuples with default values, which could be expressed in pseudo-WebIDL as: ``` typedef [GPUIntegerCoordinate = 0, GPUIntegerCoordinate = 0] GPUOrigin2D; typedef [GPUIntegerCoordinate = 0, GPUIntegerCoordinate = 0, GPUIntegerCoordinate = 0] GPUOrigin3D; typedef [GPUIntegerCoordinate, GPUIntegerCoordinate, GPUIntegerCoordinate] GPUExtent3D; ``` I previously proposed this in gpuweb#299. After discussion, we compromised on this union, and it was implemented in gpuweb#319. However there were a number of voices who didn't like the added complexity (and perceived loss of type expressivity), and since then I've come to agree that the unioned version is not the best choice.
Reserves .vscode/ ("folder settings") for personal editor settings.
This makes WebGPU app code less verbose/hard to type. Without this, I think apps are likely to have their own boilerplate helpers:
makeGPUColor = (r, g, b, a) => ({r, g, b, a}), etc.Open for debate.