Reproducible in Chrome Canary too (57.0.2953.0)

Having the same issue here:

Mac OS Sierra 10.12.2 with Chrome 55.0.2883.95 

Yes, I can reproduce that on my Mac Retina (AMD)

Was this caused by the switch to the Core Profile?

Could be, aren't line widths greater than 1 disallowed in Core Profile, or something like that?

Took a while to re-discover that --use-gl=desktop is the way to fall back to the Compatibility Profile on macOS.

gl.getParameter(gl.ALIASED_LINE_WIDTH_RANGE) returns [1, 10] with the Compatibility Profile and [1, 1] with the Core Profile. (This is on a MBP Retina with NVIDIA GPU.) It looks like Apple's Core Profile driver doesn't implement wide lines.

Note, I don't think there's anything forbidding support for wide lines in the Core Profile.

Thanks for getting to the bottom of this.  Should we file a radar to Apple?

Could you? It's not really a bug per se, but a poor implementation. Still, they'll probably be interested to know that this breaks a lot of Three.js demos:

https://github.com/mrdoob/three.js/issues/10357

The use of gl.lineWidth() should be avoided for production code. Wide lines are not supported by ANGLE on Windows and potentially several OpenGL drivers, so there's no guarantee that it works as intended. Hence you'll always need a fallback using triangles. Furthermore, unlike triangle rasterization, line rasterization is very loosely specified and is often buggy. So even when wide lines are supported, you'll get slightly or not-so-slightly different results. And for a spec compliant implementation, the joints and end caps don't actually look nice.

Here's another approach: https://mattdesl.svbtle.com/drawing-lines-is-hard

Here's one more:
https://github.com/spite/THREE.MeshLine

I'm sure Ricardo knows about these alternatives. We will still file a Radar with Apple so that they know about the regression in functionality compared to the Compatibility Profile.

Wide lines were actually deprecated in OpenGL 3.0 Core Profile: "LineWidth is not deprecated, but values greater than 1.0 will generate an INVALID_VALUE error".

That's unfortunate.  In this case, we probably should not file a radar to Apple, as we will be asking them to go against the spec.

However, we might still consider emulate wide lines in WebGL2.

Can this regression be reopened?

This regression impacts users, and I have to disagree with the opinion by Nicolas that web developers should add custom shaders to their existing pipelines to resolve it.

From a practical perspective, most orgs do not have the luxury of thousands+ of developers on staff, and thus are not in a position to follow his recommendation. I do agree with it, given that luxury.

If a principled viewpoint is needed, just because the spec leaves this explicitly unspecified, that does not mean the browser should (a) change behavior and (b) choose a weak default. 

I am surprised about the quick decision of "wontfix", and recommend fixing the regression instead.

One addition here: even the article Nicolas cited has the apropos title of "Drawing Lines is Hard", so punting here makes them harder.

Hi Leo, for what it's worth the issue was reopened by and assigned to Ken in Comment 11. More importantly he made an excellent suggestion to use THREE.MeshLine for portable wide line rendering support.

Note that this issue is Mac specific, and on Windows we never had wide lines support. So if this is impacting your users, I'm afraid a larger portion of your user base has always been affected. It's an unfortunate fact, not an opinion, that OpenGL and WebGL developers have had to work around this by rendering wide lines as polygons. It doesn't involve writing custom shaders.

For your information, we do not have thousands+ developers on staff for providing graphics driver limitation workarounds. Nor does it take that many to deal with it in application code: THREE.MeshLine.js is 460 lines of code.

In fact the issue can more easily be addressed by the application developers than by browser vendors, because we would have to support everything required by the spec. That includes things like correct varying interpolation for texturing, even though that's probably rarely used, and using the correct provoking vertex's attributes, even though that would even more rarely affect anything. Requiring such a generic implementation would make it slower. Compounding that is the need to save and restore more state than what the application would touch. Then there's also various choices in quality to make, like the fill rule, handling of overlap, corners, mitering, endpoint rounding, anti-aliasing, 1D or 2D texturing, etc. Higher quality means lower performance, and vice-versa. So even if we'd provide emulation, few professional data visualization websites would use it since they prefer to be in control of the trade-offs. Not to mention they still need things to look correct on browsers that don't provide such emulation as well.

So it's totally not worth it from a cost-benefit perspective.

Also note that most GPUs have a line width limit of 10 pixels or less. On a retina display, that's not very wide. So even the "proper" support of wide lines comes with severe and often unacceptable limitations. Which is why it got deprecated from the OpenGL specification in the first place.

So this will most likely be closed as WontFix (works as intended / invalid) again.

Hi Nicolas, thank you for the in-depth response. The decision here still seems to veer towards specific kinds of web developers, which is unfortunate.

-- Mac vs Windows: This is still a regression for Mac

-- Grey area of the standard: We should push upstream/downstream to be more usable, not less. Many GL standards improvements come from recognizing common improvements in various systems, and line width is a reasonable one.

-- Ease of fix for browser devs: The description of the above suggests communicating with related teams on the regression may go a long way. I'm less clear on the emulation side, e.g., if it is a small regression, or a one-time 500 line browser fix, or what.

-- Ease fix for app devs: First, this isn't limited to threejs users (e.g., we don't use three). Second, due to the low-level nature of gl, what's a simple change in one framework is not necessarily so in another: the one we use requires additional changes around layering, a new primitive, new data representation, etc. Third, it's pretty unclear if the perf will be a big regression or not.  

If this was enough that a team like ours spoke up, the casual developer is much worse off. The standard goes either way here, so I advocate not regressing on something so visible + making the tent bigger.

I think this requires a clarification in the WebGL spec.  We have two options:
1) forbid wide lines in general, so even on WebGL1 implementations on compatibility profiles, we also don't support wide lines
2) emulate wide lines where it's not supported, so we have ES behaviors.

One way or the other, WebGL should not have platform dependent behavior differences. Let's wait and see what the working group's vote will be.

My 2 cents, yes it sucks but as others have pointed out it's always been this way. Plenty of systems (all of windows) have only supported a linewidth of 1. If you wanted your apps to work with thick lines you've always had to implement something. This has been true since WebGL1 shipped. 

It sucks I agree but there is no browser can work around this issue in any reasonable way. They'd have to generate geometry on the fly based on whether or not you passed in gl.LINES, etc and then also magically generate shaders.

Asking GPU vendors to update their drivers is unlikely and I don't think ANGLE is going to update this on Windows either.

Given the spec even says only a width of 1 is support it seems WebGL should probably just add that as a full restriction.

Someone can post some line libraries for WebGL and devs can choose the one that best meets their needs.

Here's one BTW

https://github.com/mattdesl/three-line-2d

Cleaning up old bugs. I'm sorry, but if we tried to make a GL-compliant implementation of lines in ANGLE by generating geometry on the fly, nobody would be happy with the result; either the quality or the performance would not be good enough to satisfy everyone.

There are some very nice domain-specific implementations of wide lines available now; https://threejs.org/examples/#webgl_lines_fat is one good recent example.

I'm closing this as WontFix again. There are higher-priority issues to fix.