Polylines on Linux do not render properly if there are duplicate coordinates back-to-back

I just finished fixing a bizarre bug in my application that technically is not actually my fault. Lemme set a bit of background:

  • Users can edit routes defined by waypoints, which are displayed with an icon for each waypoint and a polyline that uses the waypoints’ coordinates
  • Routes can be “closed”, in which case I draw one extra leg from the last waypoint back to the first
    We’re using Firefox 17 as our target platform. I’ve been doing all of my dev work on Windows, but at least some of our users will be on Linux. This app is written in GWT, although another related component is plain JS.
    During testing, we got a report that route lines weren’t showing up at all on Linux. The testing was being done on a Dell Latitude E6420 with an NVIDIA 4200M card.
    While the main testing was being done against a test server with the compiled GWT app, I was able to set up a dev environment on the laptop. Sure enough, no route polylines.
    Spent multiple hours trying to tweak materials and various other fix attempts, with no luck. Oddly, copying the code from the Sandcastle Polylines demo and running it inside my app worked. Even more puzzling, if I commented out my code that applied the waypoint coordinates to the polyline, and just hardcoded a set of coordinates, my polylines showed up okay.
    It turned out that my code was doing something inefficient, but that should have been okay. For each leg of a route, I would add the start waypoint’s coordinates to my list. If the leg was not the last, or if it was the last and was closed, there would be an “end node” pointer to the next waypoint, and I would also add that waypoint’s coords. This meant that if I had a 3-waypoint route, there would actually be five coords in my list: [WP0, WP1 (end), WP1 (start), WP2 (end), WP2 (start)]. I had known that previously, but it worked, and it wasn’t like having duplicate coordinates back-to-back would be a problem, right?

Well, apparently it is. Once I revamped my code to not include all “end” coordinates, and specifically handle the case where the route is marked as “closed”, everything worked just fine.

I was able to verify the bug by running the Sandcastle Polylines demo and duplicating one of the coordinates in the “wide / outlined” polyline. Sure enough, the first leg of the polyline was okay, but the succeeding legs did not render.

I really have no idea where on the stack the problem lies. Could be Linux FF, the video card, graphics drivers, etc. But, I can definitely say this is a real issue.

Our codebase is currently using a very slightly tweaked version of Cesium b17 (nothing rendering-related).

Mark, I submitted this bug so that we can look into this: https://github.com/AnalyticalGraphicsInc/cesium/issues/898

Have you ran successfully on non-Linux machines, or do you just assume it’s Linux only?

My dev machine is WinXP, and I have FF17 Windows on here for dev work. My application code worked just fine in this setup. As it turns out, our users will actually be using FF17 on Linux (specifically RHEL 6.2), and it was testing with that environment that showed this issue.

When loading our app from a test server, the same codebase worked fine in FF17 on Windows, and showed this bug in FF17 on Linux. As I said, that would seem to indicate it’s something about the Linux side of things (hardware, drivers, etc), but it’s definitely there. Unfortunately, I don’t have any other Linux environments handy to do further comparisons on.

The simplest reproduction should be to run the Cesium Sandcastle Polylines demo straight from cesium.agi.com. Duplicate line 27 (“Cesium.Cartographic.fromDegrees(-105.0, 35.0),”) and re-run. The polyline’s first leg will draw correctly, but the duplicate third point will cause legs 2 and 3 to not render.

Mark, This issue was fixed and will be in the 1.3 release.

Sweet. Wasn’t a problem after I tweaked my code to not spit out duplicate points, but nice to see this get resolved.

Out of curiosity, what was the actual breakage involved? I skimmed the diff, but didn’t see anything obvious as to why it was breaking.