Tracking Entity - Path Jitters on iOS & new M1 Macs

[malaretv]

On iPhone browswers in the past I've noticed when tracking an entity in Cesium the path appears jittery. With the recent release of the M1 Macbooks I've noticed it happening on them also.

I've attached a video showing the phenomenon

https://user-images.githubusercontent.com/381932/110397444-dd5bad80-803f-11eb-85ca-0cc42184474b.mp4

Sandcastle example: https://sandcastle.cesium.com/?src=Interpolation.html and Select "View Aircraft"

Browser: iOS Chrome & Safari

Operating System: iOS

[srothst1]

@ebogo1 this issue and #9907 seem to be the most prominent bugs that users have noticed when running CesiumJS on an M1 Apple device.

[srothst1]

@malaretv what version of iOS are you noticing this issue on?

[malaretv]

Testing on Browserstack seems to be present in every ios + device combo i try. For sure on iOS 15, 14, and 13.

[srothst1]

@malaretv thank you for this update. How about on iOS 11 and iOS 12?

[malaretv]

Confirmed on iOS 11 and 12 also

[srothst1]

@malaretv interesting, thank you for the feedback. Errors related to tileset highlighting on M1 devices do not occur on iOS 11.

[chris-cooper]

We also see jagged/jumpy polylines on M1 devices (MacBook/iPad/iPhone) as shown in this sandcastle example. If it has been 1.5 years since this issue was reported with no update from Apple, is it possible to escalate a Cesium workaround @ggetz ?

Should be...

[ggetz]

Reported again on the forum.

[informatter]

Hi @srothst1, @malaretv I was the one that posted on the forum, and @ggetz kindly provided the link to this discussion. I have also confirmed that the jittering is not present when I tested the sand castle example I provided on the forum post on Windows. Since this seems hardware-related, what would be the best workaround for this? I have also tested the measurement tools in this example in macOS and all the measurement polylines do not have any jitter, so I am curious to know how it was bypassed. I am aware Ion is not open source, but if you guys could perhaps point me to some papers, or any literature used for working around this problem it would be very helpful.

Thanks

Nicholas

[ggetz]

Also reported by @moxizhou in #10844.

[ggetz]

@moxizhou (or any others who can reproduce this issue), could you try using WebGL 2 and see if the issue persists?

const viewer = new Cesium.Viewer("cesiumContainer", {
  contextOptions: {
    requestWebgl2: true,
  },
});

[informatter]

@ggetz still persists on my end. It looks like the M1 chip is interfering with WebGL

[ggetz]

@informatter or anyone with a M1 machine who can reproduce, could you please post your results from visiting https://webglreport.com/?

Looking into potential precision issue with M1's, it looks like there is a similar issue in webkit's bug tracker. I left a comment with the steps to reproduce the issue and will update this issue with any news.

[katSchmid]

Any progress or known workarounds? Webgl2 isn't helping for us. Below helps for desktop but not mobile althought is a bit slow

Daniel Balog 2022-03-31 01:31:49 PDT I can confirm that launching chrome canary with the aforementioned command line parameters:

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --user-data-dir=/tmp/c1 --use-cmd-decoder=passthrough --use-angle=metal

Fixes this problem + all similar problems that we've been experiencing in our applications. It's mostly about jittering vertices.

[katSchmid]

Hopefully Dean Jackson @grorgwork

WebGL 2 is enabled in yesterday's iOS/macOS/etc Safari releases. Also, everything is now running on top of Metal via ANGLE. Please test + measure your content and report bugs.

[ggetz]

Another manifestation was reported in https://github.com/CesiumGS/cesium/issues/10953.

[Williangalvani]

I can still replicate it with the sandcastle example, using Safari Version 16.3 (18614.4.6.1.6) on a M1 Mac

[StanislavNikolov]

Hi @ggetz, it looks Kimmo Kinnunen on the webkit forum thread found a workaround for this problem:

This can be worked around by adding
  invariant gl_Position;
in your shader.

Do you think Cesium could dynamically modify its shaders when running on iOS?

[baswelsh]

+1 We would love to see a fix to this - If someone can get me going in the right direction, I'd be happy to have my team pursue the fix! Thank you!!

[katSchmid]

We are getting news that the canary workaround is no longer working. Enabling metal in chrome has inconsistent results with only some entities improved. Clamping line work seems to improve visuals

[ggetz]

Also reported in https://github.com/CesiumGS/cesium/issues/11603

[vhive-jonathan-carse]

Workaround for development machines:

1. Download Chromium for Intel: https://www.chromium.org/getting-involved/download-chromium/ ( I used https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/1204193/ )
2. For some reason the Arm installer failed for me (claiming is corrupted) on the equivalent of Chrome 119 build . I will try other builds, but following Rosetta seemed to work for me.
3. Launch a Rosetta terminal (test that running "arch" produces i386)
4. I had to disable software protection because the "Open anyway" did nothing for me: sudo spctl --master-disable
5. Launch Chromium directly: ./Chromium.app/Contents/MacOS/Chromium

@ggetz Can someone from Cesium take a look at this workaround? Is it possible to find a workaround on Chrome/Safari based on this that is easier for edge clients to implement?

edit: Chromium Mac_Arm build 1192591, the match for Chrome 118, also produces "... is damaged and can't be opened" on my M1 Max Mac. Giving up on Chrome for Arm, using Rosetta with Chrome for Intel instead.

[ggetz]

Also reported with polygons in https://github.com/CesiumGS/cesium/issues/11661.

[over-ripe]

Started diving into this the other day and I tracked down the line causing the jitter, at least on polylines. This workaround prevents the compiler over-optimizing, but would be great to know if there's a better way, and if it helps with other entities besides polylines: https://github.com/CesiumGS/cesium/blob/main/packages/engine/Source/Shaders/Builtin/Functions/translateRelativeToEye.glsl

 vec4 czm_translateRelativeToEye(vec3 high, vec3 low)
 {
     vec3 highDifference = high - czm_encodedCameraPositionMCHigh;
-    vec3 lowDifference = low - czm_encodedCameraPositionMCLow;
+    vec3 lowDifference = (low - czm_encodedCameraPositionMCLow) * (1.0 + czm_epsilon7);
 
     return vec4(highDifference + lowDifference, 1.0);
 }

Edit: Found a quick alternative to forking for testing:

ShaderSource._czmBuiltinsAndUniforms['czm_translateRelativeToEye'] = 
ShaderSource._czmBuiltinsAndUniforms['czm_translateRelativeToEye'].replace("low - czm_encodedCameraPositionMCLow;",
"(low - czm_encodedCameraPositionMCLow) * (1.0 + czm_epsilon7);")

[ggetz]

Also reported in https://github.com/CesiumGS/cesium/issues/11671

[ggetz]

Also reported in https://github.com/CesiumGS/cesium/issues/11759

[ggetz]

Also reported with labels in https://github.com/CesiumGS/cesium/issues/11801.

[csciguy8]

Could not reproduce the issue on my M1 Macbook. The line looks steady, and is not jittering at all.

Macbook Pro 13-inch, M1, 2020 16GB Memory macOS Sonoma 14.2.1

Tested on: Safari (17.2.1) Chrome (121.0.6167.139) Firefox (122.0)

[malaretv]

Confirmed that I no longer see the issue in my original link when viewing from my M1 Macbook and iPhone 13

Macbook Pro 14-inch M1, 2021 MacOs Sonoma 14.2.1 Safari 17.2.1

iPhone 13 Safari 17.1

[malaretv]

Since upgrading to the latest cesium for my projects, this seems solved on all devices I saw this issue previously.

Closing this issue, though as it is an umbrella issue feel free to reopen it as needed