Set initial frontFace value to "ccw" - #313

The native APIs disagree what the default is, so the group decided to not default here, see #241 (comment)

If all native APIs provide a default value for frontFace, I don't see why Web GPU API should not provide one as well. No matter what the value is.

There are cases where web developers don't care about the frontFace value. Even though Web GPU is an explicit API, we should do our best to ease things when we can, and this seems like an easy thing to do.

If all native APIs provide a default value for frontFace, I don't see why Web GPU API should not provide one as well. No matter what the value is.

If there was the same value defaulted by the API, then I'd happily agree with you. If it's different, there is no huge need for us to pick one.

There are cases where web developers don't care about the frontFace value.

We shouldn't optimize the API ergonomics for the minority of cases. A scenario "I don't care, so I pick any" to me is much more affordable (from the API design perspective) than "I do care, but now I have a bug because I missed it", which affects not just the writing code experience, but also examples, reviews, etc.

Even though Web GPU is an explicit API, we should do our best to ease things when we can, and this seems like an easy thing to do.

Ergonomics of this API isn't high on the list. Portability, security, performance - these are top priorities. Digging the pit of success for the user - this is high for me: making sure the code is clear to read and that the change to accidentally making an error is low. This applies to the frontFace default.

If there was the same value defaulted by the API, then I'd happily agree with you. If it's different, there is no huge need for us to pick one.

The value of the default doesn't matter but I think having a default is important: it doesn't matter for experienced developers that know frontFace is a thing and have a convention in their engine, but it helps people starting to use WebGPU by removing unnecessary noise. frontFace is even better in that the other defaults (for cullMode and stencil front/back) make it so cww or cw don't have any effect if the other values in the descriptor are defaulted.

Ergonomics of this API isn't high on the list. Portability, security, performance - these are top priorities. Digging the pit of success for the user - this is high for me: making sure the code is clear to read and that the change to accidentally making an error is low. This applies to the frontFace default.

While ergonomics is lower on the list, I believe that having defaults for harmless values like frontFace doesn't trade any portability, security or performance and doesn't move us out away from the pit of success.

it helps people starting to use WebGPU by removing unnecessary noise

I don't see how this is an unnecessary noise. Back face culling is ubiquitous. And since we are not the source of vertex/mesh data for the user, it's their responsibility to communicate to us what convention that data uses.

I would argue that a case where frontFace doesn't make a difference - drawing screen-space aligned quads - is more on the advanced side (post-fx or UI systems) than drawing simple meshes, which means having a default there doesn't help a novice developer anyway.

While ergonomics is lower on the list, I believe that having defaults for harmless values like frontFace doesn't trade any portability, security or performance and doesn't move us out away from the pit of success.

This is true, it doesn't harm any of the hard requirements we have on the API. What it affects is how we play with the ecosystem: do we state an opinion that we try to push downstream, or do we stay unopinionated? It doesn't appear to me that stating the opinion brings us any closer to these goals either.

We can always add a default later, but never take one away.

As a developer, I've been tripped up by the differing frontface defaults before during ports between D3D/GL, and it's still common to see people reverse cull mode instead of setting the proper front face, so at least adding that slight moment of pause might be helpful.

I don't see how this is an unnecessary noise.

@beaufortfrancois is currently learning WebGPU, and this noise is making it more difficult to understand the API, even if I'm right there to explain things. Also he is looking at how to make articles to teach WebGPU 101 to evangelize the API and this kind of noise will scare people away. frontFace is just one example and there are many others things that make even the most simple WebGPU examples feel "experts-only".

@Kangz I fail to understand how you call frontFace "experts-only" while the very same tutorials create pipelines, bind groups and layouts, command and pass encoders, do mapping and submissions, etc.

Imagine you come from a Javascript background and maybe have used three.js but not WebGL itself. If we want to teach you WebGPU from the basics and start with a 30-line render pipeline descriptor that introduces 10 different concepts including frontFace, it looks "experts only". Meaning that you already need to be an expert to understand that API. It may not be true but this matters for beginners, and has no costs for more advanced users of the API.

One thing that is certainly awkward is that frontFace is a strange pick for "the only required field". An alternate solution to this might be to make a few more fields required as well, so instead of createRenderPipeline({ frontFace: 'cw' }), you get createRenderPipeline({ cullMode: 'none', frontFace: 'cw', depthTest: 'lequal', depthWrite: true }), which feels more balanced.

API ergonomics is a strange thing to quantify, but I feel if we're going to have a few fields be required, they should be the ones that count. It doesn't really harm professionals either, since they're going to be passing everything anyway, and being explicit can be friendly to beginners.

Some of us were thinking of perhaps letting frontFace be optional in webidl, but have unset-frontFace with triangle prims be a validation error.

Just for a little extra context, IIRC we previously discussed merging frontFace with cullMode. (It may seem like frontFace doesn't matter if culling is disabled.) But there was at least one reason we couldn't do that: gl_FrontFacing (Were/are there others?)

Still, maybe there is value in a specced default that's only allowed with cullMode "none", under the assumption that caring about the winding order without culling is relatively rare.

I.e. GPUFrontFace frontFace;: not required, but no default. Only valid to omit frontFace with cullMode: "none", in which case it means "ccw".

frontFace also interacts with the stencilFront and stencilBack members of the GPUDepthStencilDescriptor. We could allow it not being present when the primitiveTopology isn't triangle based.

Do we expect non-triangle-based topologies often? If this is raised because it's awkward for beginners to use, I don't expect point/line topologies to be part of that use case.

Agreed, although, in addition to a "learning" cost, there's also an "annoyance" cost. And I think in cases where there's no downside to reducing the annoyance cost, we should.

Discussed at 25 Jun 2019 teleconference

Resolution: merge without changes.