Documented guaranteed swap chain formats and validation - #1185
Conversation
|
The idea is that both the device and the canvas may have some impact on the preferred type. You could imagine having a canvas on one display that's HDR/WCG, and one on another display that's not, and the preferred types could be different. In practice I'm not 100% sure how browsers will use this info especially given canvases can be moved between displays. Probably the best way to store info that's keyed on The list of supported formats should be very small, and in fact I think we should enforce by spec that the only allowed formats are the guaranteed formats + the single value returned by I think the returned value of |
|
Awesome, thanks for the feedback! I rearranged things quite a bit after considering your suggestions. I am using a map now, but it's stored on the |
| **Returns:** {{Promise}}<{{GPUTextureFormat}}> | ||
|
|
||
| Issue: Describe {{GPUCanvasContext/getSwapChainPreferredFormat()}} algorithm steps. | ||
| 1. Let |promise| be [=a new promise=]. |
There was a problem hiding this comment.
The more I think about it, the more it seems like this could be synchronous: either the canvas is HDR and the preferred format is rgba16float or rgb10a2unorm depending on how it was configured, or it is not HDR in which case it is best as bgra8unorm on all OSes except Android where it is best rgba8unorm. Basically we know synchronously on canvas context creation what's the best format.
There was a problem hiding this comment.
I think we need to put some more thought into this (with input from platform/canvas experts) because, like I mentioned above, I'm not exactly sure how browsers are going to handle this. Why do we need the canvas - is it because we can check which display the canvas is on? What happens if the canvas moves between displays, does the result here change? Do we instead provide the "max" of all the attached displays? What happens if there's a non-HDR display and an HDR display and you unplug the HDR display?
|
Update this PR to take into account conclusions from today's call. PTAL! |
kainino0x
left a comment
There was a problem hiding this comment.
I thought one of the outcomes from today's call was that we would have fixed sets of allowed formats, consistent across all systems, and the preferred format would always be one of them. So for the default case, this might just be bgra8unorm and rgba8unorm. Maybe we should write the spec for now such that only those two are allowed?
In particular, I'm not sure whether it makes sense to have the -srgb variants in there by default. They might only be available when the canvas context has been created with CanvasColorEncodingEnum "unorm8-srgb"? See https://github.com/WICG/canvas-color-space. (Also, note it currently says "Support for "unorm8" is mandatory. All other encodings are optional." I would very much like to be able to require srgb support...)
HDR is probably just rgba16float, though maybe we need rgb10a2unorm, I'm not sure (note CanvasColorEncodingEnum doesn't have such a thing now). Similarly we may only allow these formats if the canvas context has been created with some special flags in the first place.
Alternatively, maybe we shouldn't use the CanvasColorEncodingEnum part of canvas-color-space at all, and instead express it using our own (more concrete) texture formats in swap chain creation.
I think @jdashg shared that on some hardware the optimal format for canvases is |
3f9cfc3 to
e7f5c1b
Compare
I missed that particular distinction, thanks for catching it. I've limited the list to |
|
Updated to simplify the preferred format and move it to the adapter as Kai suggested. Left the sRGB formats in the supported list since that's the outcome I recall from yesterday's call. I also vaguely remember someone (maybe @jdashg?) suggesting that a FP format should be in that list as well but couldn't find reference to that in the minutes so I've omitted it for now. |
|
Still LGTM, though we (at least I) still need to do some work understanding how srgb should work exactly. We should also figure out separately:
|
eb05f01 to
0ef0862
Compare
|
Updated to remove the |
Adds some text indicating which formats swapchains must support, and uses it in some validation for the swap chain configuration.
I suspect this will need some iteration to get to a happy place, and once the editors are good with the layout we'll probably want to get confirmation from the WG that the documented formats are indeed what everyone agrees on. I have some questions/concerns to start:
GPUCanvasContextplay in controlling the supported formats? I have all that info stored on the device now, but you wouldn't need to get the preferred format from the context if it didn't have some effect on the outcome. SHould both the device and the context have a list of supported formats and the validation happens against the ANDed union of the two? Similarly should each have a list of supported formats in order of preference and the preferred format returns the first entry that appears in both lists? If so, what is the context's list generated from?Preview | Diff