这是indexloc提供的服务,不要输入任何密码
Skip to content

createRenderPipeline with preferred format is dependent on canvas #2747

@kainino0x

Description

@kainino0x

I noticed this issue while investigating canvas questions. The problem:

If you want to use preferred formats, then you must know the preferred format in order to create render pipelines that output to the canvas. But you must have the canvas to know the preferred format. If an application outputs to multiple canvases or reconfigures its canvas, this makes it look like it may need to recreate render pipelines on canvas setup - or cache two render pipelines with different formats. In practice, I am pretty sure this is never necessary: desktop prefers bgra8unorm, and mobile prefers rgba8unorm; the canvas/display/adapter doesn't matter. (Verifying this is an open question.)

I think we originally envisioned that getPreferredFormat could help you choose between formats depending on whether the display is HDR. But I've decided this is the wrong API for that: applications that want to support HDR should detect the dynamic range of the display (e.g. using the CSS dynamic-range media query, plus some way of detecting when that media query changes due to windows moving between displays), and knowing that, may switch a lot of codepaths, not limited to the canvas format (intermediate texture formats, tone mapping, etc.)

So I'm deliberately proposing scoping down the purpose of the "preferred format" API to only SDR formats rgba8unorm and bgra8unorm. Later we may want to add a separate API like getPreferredHDRFormat (for rgba16float vs rgb10a2unorm), or extend getPreferredFormat with a list of options to choose from, that the app can check when it has determined it should use HDR output.


My proposal is to move preferred format out of GPUCanvasContext.getPreferredFormat(GPUAdapter) (proposal 0), to a global navigator.gpu.getPreferredCanvasFormat() (a function, for extensibility) (proposal 1). Alternatively, it could move to a GPUAdapter.getPreferredCanvasFormat() (proposal 2), but since you may use an adapter other than the one physically connected to a display, this seems mis-associated.

If it is actually possible for two different displays(/adapters) to prefer different SDR formats, then proposal 0 probably still makes sense - though maybe we can remove the GPUAdapter argument from GPUCanvasContext.getPreferredFormat() (proposal 0b).

Metadata

Metadata

Assignees

No one assigned

    Labels

    copyeditingPure editorial stuff (copyediting, *.bs file syntax, etc.)

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions