[Bug] TripsLayer's vTime has rendering problems when the segments are short with precise timestamps

Description

I had an issue with the TripsLayer: it was mis-rendering the beginning of my trip paths.

It's similar than what is described there:

• https://github.com/visgl/deck.gl/discussions/7975
• https://github.com/visgl/deck.gl/discussions/8775

After debugging for a while, I noticed that the rendering bug was only present when precise timestamps were used, such as the unix epoch in seconds or microseconds. The scale of the numbers didn't really seem to matter. Dividing the timestamp by one million and updating updateTime and trailLength accordingly didn't prevent the rendering bug. Maybe my dataset has too many points, or points too close to each other.

I'm not an expert with deck.gl and shaders, but I feel like it's a precision issue on the vtime there:
https://github.com/visgl/deck.gl/blob/a51fc6966994b1fcb90a534baf563b3cd1444f0a/modules/geo-layers/src/trips-layer/trips-layer.ts#L77

In my case, I replaced the calculation by the much simpler following code because my data has enough points:

vTime = instanceTimestamps;

This issue has been useful to me: https://github.com/visgl/deck.gl/issues/6844

Flavors

• Script tag
• React
• Python/Jupyter notebook
• MapboxOverlay
• GoogleMapsOverlay
• CartoLayer
• ArcGIS

Expected Behavior

Steps to Reproduce

• A trip layer with a simple path.

In my case:

[
[14.959, 68.9856],
[14.954, 68.9902],
[14.95, 68.9948],
[14.946, 68.9994],
[14.939, 69.007],
[14.932, 69.015],
[14.925, 69.023],
[14.921, 69.0275],
[14.916, 69.032],
[14.912, 69.0365]
]

• And a set of timestamps that have many digits.

Environment

• Framework version: 9.0.16
• Browser: Microsoft Edge 125.0
• OS: MacOS Sonoma 14.5

Logs

No response

Start in modules/geo-layers/src/trips-layer/trips-layer.ts around the vTime calculation at line 77. Reproduce the React TripsLayer case with the supplied path and high-precision timestamps, then compare rendering with the timestamp handling described in the issue. Done means short segments render correctly with precise timestamps without requiring the reported workaround.