Timelapse map disappears

[jaredko]

Whenever I try to play a timelapse, the map shows briefly, but then goes white. I can still see the controls, but the boat and track are missing. Tried in chrome + edge, on multiple laptops.

[admin]

Hi @jaredko , we can not reproduce it. Is it happening for all timelapses? Is is it with the new or old UI or both? I am wondering if it has something to do with graphics acceleration on the computer, but multiple laptops eliminate that possibility.

Can you send a link that is broken for you?

[jaredko]

Hi thanks for taking a look. Yes, my public timeline link shows the behavior:
https://saillogger.com/svtrillium/timelapse

[jaredko]

Any updates? Seems to be just the new UI. If I set it back to the old UI it works.

[admin]

Sorry @jaredko , your timelapse renders perfectly fine when we try. The only I can suspect is rendering engine, is it happening on all devices? It is really strange as we cannot observe what you are observing on your timelapse.

[jaredko]

Tried the AI assistant built into the chrome dev console. It suggests a few different root causes related to the canvas size. I confirmed changing my display scale from 125% to 100% in windows 11 fixes the isssue on desktop and is probably why you don't see it on your side. Still broken on my Pixel 10 pro, but looks like it always worked on my Ipad 13 pro.

If the canvas size is tied to the dimensions of the track, I've sailed from South Africa to the US and the Med, so that could be a factor?

Here's what the AI says.

Bug Report: GPU Crash & WebGL Overflow on High-DPR Devices
Symptoms:

Crash: Map displays a "white screen" or "unhappy face" icon (GPU process crash) on high-DPR devices (e.g., Pixel 10 Pro, or desktops with >100% scaling).
Console Error: GL_INVALID_VALUE: glTexSubImage2DRobustANGLE: Offset overflows texture dimensions when switching layers.
Reproducibility: Works at 100% scaling (DPR 1.0), but fails consistently at 125% (DPR 1.25) or mobile scales (DPR 3.0+).

Root Causes
Massive Canvas Allocation ($2^{25}$px): The element canvas.tl-head-canvas is attempting to set its width and height attributes to 33,554,432 ($2^{25}$). This is likely caused by a logic error where map coordinates or zoom levels are being multiplied by window.devicePixelRatio without being clamped to the viewport size.

Why it fails on mobile: A Pixel 10 Pro has a high DPR (3.0–4.0). The math hits this $2^{25}$ limit significantly faster than on a 1.0 DPR screen.
Sub-pixel Mismatch (DPR 1.25): At a 1.25 scale, a CSS width like 570px results in 712.5 physical pixels. The browser rounds the canvas to 712, but the WebGL engine (MapLibre/Mapbox) attempts to update a texture at the 712.5 offset. This "overflows" the actual 712px texture boundary, triggering the glTexSubImage2D error.

---

Recommended Fixes

1. Clamp Canvas Dimensions (Immediate Fix for Crash)
   Ensure that any code resizing the tl-head-canvas (or any overlay canvas) is clamped to the actual viewport size or the maximum texture size supported by the GPU.

js

// Example fix in the resize handler:
const MAX_SIZE = gl.getParameter(gl.MAX_TEXTURE_SIZE) || 4096;
canvas.width = Math.min(calculatedWidth, MAX_SIZE, window.innerWidth * window.devicePixelRatio);
canvas.height = Math.min(calculatedHeight, MAX_SIZE, window.innerHeight * window.devicePixelRatio);
Use code snippets with caution

2. Normalize Container Dimensions
   To prevent the Offset overflows error, ensure the map container always has integer physical pixel dimensions.

js

// Force the container to an integer-friendly size
const rect = container.getBoundingClientRect();
const dpr = window.devicePixelRatio;
container.style.width = ${Math.floor(rect.width * dpr) / dpr}px;
container.style.height = ${Math.floor(rect.height * dpr) / dpr}px;
Use code snippets with caution

3. Check Pointer-Events on Overlays
   The .tl-side container has pointer-events: none globally, but the buttons inside it do not consistently have pointer-events: auto applied, which can block interactions on some mobile browsers even if the crash is avoided.