The preferred formats rgba8unorm and bgra8unorm have almost the same capabilities, except for one: STORAGE_BINDING usage. This limitation is not universal on underlying APIs: bgra8unorm storage is supported always on Metal, never on D3D12, and sometimes on Vulkan (if my investigation is correct).

Meanwhile, rgba8unorm incurs some emulation or copying on Mac: #2535. For use-cases that want to store into the canvas texture, bgra8unorm would be highly preferable on Mac (since bgra8unorm storage is always available).

• option 0: Leave as is; if you need storage you use rgba8unorm and incur overhead on mac.
• option 1 (EDIT: Landed for V1 in Add "bgra8unorm-storage" feature flag #2838): Add a "bgra8unorm-storage" feature flag - straightforward and explicit.
  This wouldn't be testable on a lot of machines, which means anyone who doesn't explicitly check for support (and test on Mac) is putting Mac at a perf/power disadvantage. However, this is pretty much the same trade-off as getPreferredFormat on desktop vs mobile.
  • May want to add texture usage to getPreferredFormat: Return the platform-preferred format unless STORAGE is requested. If you request STORAGE, then in core it always gives RGBA, but if the bgra8unorm-storage feature is enabled, may give you BGRA. Console warning if you ask for storage, and the feature is available but not enabled.
• option 2: Add two new "magic" formats rgba8unorm-unordered-nonstorage and rgba8unorm-unordered-storage. These would be non-copyable but otherwise the same as rgba8unorm/bgra8unorm.
  • This swings far to the side of "declarative", so apps don't have to get their logic right to do the right thing (call getPreferredFormat with the right arguments). But as with many declarative things, it's inflexible: might we find other restrictions that make this short-sighted?
  • It also creates a bunch of strict validation, e.g. if your canvas is rgba8unorm-unordered-nonstorage then your render pipeline MUST also be rgba8unorm-unordered-nonstorage.
  • Can technically replace getPreferredFormat (createRenderPipeline with preferred format is dependent on canvas #2747), but likely should keep something like that because new formats won't map well to existing engines porting from WebGL/native (think Unity/Unreal).

Both options 1 and 2 could be done post-V1. Adding V1 milestone for initial discussion.