I don't know anything about gpu-rasterization-msaa-sample-count, but I'm pretty sure it doesn't impact WebGL.

That said, it does seem wrong that gl.SAMPLES always returns 0. It reproduces for me on:

Google Chrome	72.0.3623.3 (Official Build) dev (64-bit)
Revision	62566d37ac342c0932ceb403043dc1ab699fc21d-refs/branch-heads/3623@{#7}
Platform	11307.0.0 (Official Build) dev-channel eve
Firmware Version	Google_Eve.9584.174.0
Customization ID	GOOGLE-EVE
ARC	5151026

marcheu / dcastagna: could someone from the ChromeOS team take a look and see if there is a driver issue on this device? Thanks.

Isn't that because of CMAA?

Ah, that would make sense. My about:gpu doesn't show CMAA though, should it be there?

Seems odd to return 0 instead of 1, but with CMAA there is physically only one sample per pixel AFAIK.

Thanks marcheu@ and kainino@ for looking at this.

CMAA is on by default on Intel GPUs on ChromeOS with only a few exceptions (see src/gpu/config/gpu_driver_bug_list.json). The actual texture is a non-multisampled texture and I think querying GL_SAMPLES returns 0 for those, to distinguish them from multisampled renderbuffers with 1 sample.

Submitter: this is basically per spec. What would you like to feature detect about the state of WebGL's back buffer in this case?

Thanks for the fast responses!
CMAA is definitely what I'm looking at. Given that, I think GL_SAMPLES returning 0 makes sense here, as I can detect this situation and work around it. We can close this bug I think.

I don't know much in this area, is CMAA instead of MSAA a performance optimization for cheaper hardware? Compare CMAA to MSAA (--disable_framebuffer_cmaa) for this animation on a Pixelbook: https://codepen.io/anon/pen/OrMpzz?editors=0010
With CMAA thin shapes have a tendency to disappear.

Linking to the CMAA issue.

CMAA is an Intel technology that is cheaper than MSAA. You can read about it here:
https://software.intel.com/en-us/articles/conservative-morphological-anti-aliasing-cmaa-update

We could consider switching from CMAA to 4x MSAA on some hardware. https://crbug.com/768400#c33

+Yunchao and Yang from Intel as an FYI about CMAA's quality in certain situations.

Submitter: have you tried allocating your own MSAA renderbuffers and working with them directly on this hardware, and then doing a final blit to WebGL's (non-antialiased) back buffer? If so is the performance acceptable?

AFAIK we'd have to update to WebGL2 to use multi-sampled renderbuffers. I did try editing several large documents with and without --disable_framebuffer_cmaa, and I didn't notice a significant difference in frame rate between the two. (But without CMAA, the visual experience is much better.)
We're typically not GPU bound, so I suspect that approach would work if we really wanted to have tight control over antialiasing.

OK, I see. Thanks for the feedback.

Please tell us if we need to provide some query to inform apps like yours of the antialiasing method of the back buffer. In the interim, per your suggestion above, closing as WontFix.