GL line width + pixel ratio woes

[IanLilleyT]

This is the new home of the GL line width sub-issue in #8113

There are two problems with using GL lines with varying resolution scale:

1. Some vendors don't support line widths greater than 1, which results in very thin lines at high pixel densities:

Width 1 at low resolution scale

Width 1 at high resolution scale

2. RenderState doesn't have access to FrameState which has the pixelRatio value. So even if we wanted to multiply the line width with pixel ratio, it would require a refactor.

My thinking is we shouldn't be using GL lines for anything, mainly because of the first problem, and should instead use polylines. Chances are this issue will stay on the back-burner for a while since this is low-impact problem, but glad to hear other's thoughts.

[OmarShehata]

There's been some discussion here #6694 on switching polygon outlines to polylines for both the line thickness and ability to clamp it to terrain.

[emackey]

My thinking is we shouldn't be using GL lines for anything, ... and should instead use polylines.

👍

[thw0rted]

Hey @OmarShehata @emackey , can this get a priority assigned? I just started working with some data from a system that replicates a lot of Cesium's drawing primitives but their backing engine handles shapes with both stroke and fill as you'd expect, so there's an obvious difference when drawing the same thing on their system vs mine. I added a separate polyline when it's a basic polygon, but there's going to be more work involved for circles, ellipses, corridors (especially those), etc. It would be great if Cesium handled the heavy lifting here.

[OmarShehata]

It would be great to see too, this but I'm not sure when exactly we'll be able to get to it.

[thw0rted]

I just noticed another place where this is a problem -- when you load GeoJSON (with GeoJsonDataSource), it takes a strokeWidth option, but it doesn't actually work when the feature is a polygon.