Thank you for the report..
Considering this as Feature request, marking as Untriaged and requesting Dev team to look into this and update accordingly.

Note that you might get better results by using 2D canvas to render text. With the "alpha: false" context creation parameter, Chrome will also produce subpixel-antialiased ("LCD"/ClearType) text. This will only work when the text is strictly screenspace-aligned (not transformed), so it may or may not be applicable to your use case.

That said, it should be possible to add a command-line flag for WebGL MSAA samples. There already exist flags for canvas (--canvas-msaa-sample-count) and GPU rasterization (--gpu-rasterization-msaa-sample-count).

Thanks for the feedback. In our case we cannot use the 2D context as the UI and 3D rendering is all intermixed, i.e. the 3D space is part of the UI.

Would be great to have an option to set this, or even better, use 8x8 by default like Safari ... :)

It's possible to render text to a 2D canvas and then upload to a WebGL texture from that canvas. Or to get an ImageBitmap of the 2D canvas and upload that. I'm not sure if this would be performant enough.

My understanding is that rendering fonts as MSAA triangles is considered overly expensive, and it's less portable. More common font rendering techniques include:
* Rendering all glyphs into a big texture atlas at 1:1 pixel scale[1] and then rendering quads for each character pointing at different parts of the atlas. Should be fast but doesn't allow text scaling.
* Similar, but render distance fields into the texture atlas and do the rendering in the fragment shader using distance fields. This allows reasonably good text scaling without re-rendering fonts.

[1] This can be done by rendering text into a 2D canvas and uploading that 2D canvas as the texture atlas. This lets you use the browser's text rendering engine, so fonts should be "pixel-perfect"

All that said, we should also of course consider the feature you're requesting. I don't know why we use 4x4 by default instead of 8x8 on a system which supports 8x8.

We could switch WebGL to use an 8x MSAA framebuffer by default on devices where that's supported. I think the only reason we chose 4x MSAA was for portability and performance.

Kai, would you be willing to add the needed query to DrawingBuffer.cpp? It should be an easy fix.

Changing the spec would take more time.

(You assigned this to yourself, did you mean to assign this to me?)

Sorry, I'm about to leave for 2 weeks, and I need to wrap up everything else I'm doing before I pick up anything new.

Oops, I did mean to assign this to you.

I'll take this after all. Enjoy your vacation.

Thanks for taking this on, 8x8 MSAA in Chrome would be fantastic!

Thanks also for the suggestions for rendering the fonts. We tried out a lot of solutions. In a complex UI, we have 50+ text elements we have to render in 60fps, these are different fonts, sizes, styles. As our layout system is dynamic and any part can be resized and changed by the user, managing pre-rendered fonts efficiently is a nightmare. It's a different situation for a game which has a limited amount of text and mostly only one font style. We found that rendering text (and in our case also SVGs for the icons) as triangles is flexible, fast and works everywhere (just does not look too good on 4x4).

Anyway, with 8x8 AA we are nearly there. Considering that native OpenGL contexts can do 12z12 or 16x16 with no problem, I assume it is only a matter of time until these are also available in a browser ? But 8x8 is actually good enough for a browser use case anyway.

Another story is iOS, on an iPad (which is a realistic target for our apps) even on a modern iPad Pro, the AA is 0x0 ... .

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cdc786f5d2a2b538f4914ba0afbaee15634206b9

commit cdc786f5d2a2b538f4914ba0afbaee15634206b9
Author: Kenneth Russell <kbr@chromium.org>
Date: Sat Sep 16 21:07:21 2017

Use 8x MSAA rather than 4x MSAA when available.

Should produce higher quality antialiasing for all WebGL apps with
hopefully not too much of a performance impact. Apparently Safari
already uses this setting.

BUG= 730303 

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I4e280ded388996b453a0b306c787b9829210bcf0
Reviewed-on: https://chromium-review.googlesource.com/669036
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Cr-Commit-Position: refs/heads/master@{#502513}
[modify] https://crrev.com/cdc786f5d2a2b538f4914ba0afbaee15634206b9/content/test/gpu/gpu_tests/pixel_expectations.py
[modify] https://crrev.com/cdc786f5d2a2b538f4914ba0afbaee15634206b9/content/test/gpu/gpu_tests/pixel_test_pages.py
[modify] https://crrev.com/cdc786f5d2a2b538f4914ba0afbaee15634206b9/third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp

Oops, forgot I need to undo the failure expectations.

Based on the failures of the try job:
https://chromium-review.googlesource.com/c/chromium/src/+/670122

it looks to me like there were stale reference images in cloud storage for these three tests:
https://pantheon.corp.google.com/storage/browser/chromium-gpu-archive/reference-images?prefix=Pixel_2DCanvasWebGL
https://pantheon.corp.google.com/storage/browser/chromium-gpu-archive/reference-images?prefix=Pixel_WebGLGreenTriangle_AA_Alpha
https://pantheon.corp.google.com/storage/browser/chromium-gpu-archive/reference-images?prefix=Pixel_WebGLGreenTriangle_AA_NoAlpha

I'm going to increment the revision for these three tests again to force new reference images to be generated.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/46dddca043a88a5377f2daa7fcafe307a6613fb5

commit 46dddca043a88a5377f2daa7fcafe307a6613fb5
Author: Kenneth Russell <kbr@chromium.org>
Date: Wed Sep 20 04:09:51 2017

Generate new reference images for antialiased WebGL pixel tests.

It looks like there are stale reference images in cloud storage for
the following three tests:

Pixel_2DCanvasWebGL
Pixel_WebGLGreenTriangle_AA_Alpha
Pixel_WebGLGreenTriangle_AA_NoAlpha

BUG= 730303 
TBR=zmo@chromium.org

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ifb6f397799278083c19388e04d8bfce7da557b15
Reviewed-on: https://chromium-review.googlesource.com/674061
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503043}
[modify] https://crrev.com/46dddca043a88a5377f2daa7fcafe307a6613fb5/content/test/gpu/gpu_tests/pixel_test_pages.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fd2f63d97787af00c5975d465af4bd836c4f56e5

commit fd2f63d97787af00c5975d465af4bd836c4f56e5
Author: Kenneth Russell <kbr@chromium.org>
Date: Fri Sep 22 05:12:19 2017

Remove expected pixel test failures after change to 8x MSAA.

BUG= 730303 
TBR=zmo@chromium.org, kainino@chromium.org

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I6bda49c9d920465cd4bbd6f8401cf37860ed9adf
Reviewed-on: https://chromium-review.googlesource.com/670122
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503665}
[modify] https://crrev.com/fd2f63d97787af00c5975d465af4bd836c4f56e5/content/test/gpu/gpu_tests/pixel_expectations.py

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/687cb227f2d9a18d632a2657773b0a52889b1c49

commit 687cb227f2d9a18d632a2657773b0a52889b1c49
Author: Kai Ninomiya <kainino@chromium.org>
Date: Sat Apr 14 03:28:30 2018

Limit MSAA to 4x on Android devices

These devices tend to be hi-dpi, and low-power. 8x MSAA has also been
seen to trigger various bugs, and impacts performance on some devices.

Bug:  797243 ,  730303 
Change-Id: I41f1ef387009f1f63dff82ecb1f3737d3a0c22aa
Reviewed-on: https://chromium-review.googlesource.com/1013279
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550873}
[modify] https://crrev.com/687cb227f2d9a18d632a2657773b0a52889b1c49/gpu/config/gpu_driver_bug_list.json

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/687cb227f2d9a18d632a2657773b0a52889b1c49

commit 687cb227f2d9a18d632a2657773b0a52889b1c49
Author: Kai Ninomiya <kainino@chromium.org>
Date: Sat Apr 14 03:28:30 2018

Limit MSAA to 4x on Android devices

These devices tend to be hi-dpi, and low-power. 8x MSAA has also been
seen to trigger various bugs, and impacts performance on some devices.

Bug:  797243 ,  730303 
Change-Id: I41f1ef387009f1f63dff82ecb1f3737d3a0c22aa
Reviewed-on: https://chromium-review.googlesource.com/1013279
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550873}
[modify] https://crrev.com/687cb227f2d9a18d632a2657773b0a52889b1c49/gpu/config/gpu_driver_bug_list.json

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fc3de2e7d607be28983f8e60a1d258ea1036d054

commit fc3de2e7d607be28983f8e60a1d258ea1036d054
Author: Kai Ninomiya <kainino@chromium.org>
Date: Tue May 22 22:11:22 2018

Limit MSAA to 4x on Android devices

These devices tend to be hi-dpi, and low-power. 8x MSAA has also been
seen to trigger various bugs, and impacts performance on some devices.

Bug:  797243 ,  730303 
Change-Id: I41f1ef387009f1f63dff82ecb1f3737d3a0c22aa
Reviewed-on: https://chromium-review.googlesource.com/1013279
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#550873}(cherry picked from commit 687cb227f2d9a18d632a2657773b0a52889b1c49)
Reviewed-on: https://chromium-review.googlesource.com/1069422
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#680}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/fc3de2e7d607be28983f8e60a1d258ea1036d054/gpu/config/gpu_driver_bug_list.json

Tested the issue on chrome reported version# 58.0.3029.110(Build without fix) and on latest beta# 67.0.3396.56(build with fix) using mac 10.12.6 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: www.paintsupreme.com and www.raysupreme.com
2) Observed the UI on both the chrome versions, didn't observed any UI difference on both the builds

@Reporter: Please find the attached screencasts(730303 - 58.0.3029.110 & 730303 - 67.0.3396.56) for your reference and let us know if we missed anything in verifying the fix, please help us in confirming the fix.

Thanks!

Deleted: 730303 - 58.0.3029.110.mp4 2.2 MB

	730303 - 58.0.3029.110.mp4 2.2 MB View Download

Deleted: 730303 - 67.0.3396.56.mp4 1.9 MB

	730303 - 67.0.3396.56.mp4 1.9 MB View Download

The fix is confirmed from our side. We changed the way we draw text in the UI (from WebGL to the 2D canvas) that is why the change in the default backbuffer to 8x8 is not that obvious anymore in the main UI.

However it helps us a lot in dedicated WebGL based views.

Thanks a lot for implementing the 8x8 backbuffer!

You're welcome! Thanks for helping verify.