Lightbox flickers on Android only when Google Maps is rendered underneath

[miag676]

Hi, I’m seeing an Android-specific flickering issue with yet-another-react-lightbox, but only when a Google Maps map is rendered underneath the lightbox.

On Android phones, if I open the lightbox over a Google Maps map and swipe between the images enough times, the whole lightbox/page occasionally flickers. It does not happen on every swipe, but after moving between images for a while it happens.

When the flicker happens, it affects the image and also the buttons in the top-right corner, so it looks like the whole lightbox layer briefly redraws or flashes.

I only see this when Google Maps is open/rendered underneath the lightbox. If the lightbox is tested without the map underneath, I do not see the same flickering.

• Are there recommended CSS or lightbox settings to isolate the lightbox from the map underneath?
• Separately, on iOS the flicker does not happen, but image loading feels much slower. Is there a known reason why large images might load or render more slowly in the lightbox on iOS Safari compared with Android Chrome?

Minimal sandbox:
https://codesandbox.io/p/github/miag676/lightbox/master

Thanks a lot in advance!

[igordanchenko]

Hi,

Thank you for the detailed report and the repro. I haven't reproduced the flicker myself since I don't have a test Android device on hand, but your description pinpoints the cause pretty clearly. I looked into both problems, and they share the same root cause. Neither is a lightbox bug, and unfortunately there is no CSS setting that can isolate the lightbox from the map, because it's not a stacking or paint-order problem. Here is what's going on.

Android flickering

The images in your repro are full-size camera originals — 4000×3000 (12 MP), up to 9.6 MB each. A decoded 12 MP image takes roughly 48 MB of GPU memory, and since the carousel keeps the adjacent slides mounted for smooth swiping, moving between slides churns through 100–150 MB of GPU texture uploads.

Google Maps is the second half of the equation. It renders through a WebGL canvas that holds its own large GPU allocation and keeps repainting on every frame — even underneath the lightbox. Two things in your setup make that worse:

• Your backdrop is translucent (alpha(grey[900], 0.9)), so the map is still visible and Chrome must keep compositing it on every frame — it can't skip the layers underneath.
• noScroll={{ disabled: true }} keeps the page fully live under the lightbox.

GPU memory on Android phones is limited. After enough swipes, Chrome hits memory pressure and drops and rebuilds its compositor layer tree, which re-rasterizes the entire overlay at once — that's exactly the symptom you're describing, where the image and the toolbar buttons flash together. Without the map there is enough GPU headroom, so it never triggers.

What I recommend, in order of impact:

1. Serve appropriately sized images. This is the real fix, and it will almost certainly make the flicker unreproducible on its own. The preferred approach is to provide multiple resolutions via the slide srcSet — it's the most reliable and flexible option across various viewport sizes and pixel densities, and the lightbox natively picks the best candidate for the viewport:

   {
     src: "/images/photo-1920.jpg",
     width: 1920,
     height: 1440,
     srcSet: [
       { src: "/images/photo-640.jpg", width: 640, height: 480 },
       { src: "/images/photo-1280.jpg", width: 1280, height: 960 },
       { src: "/images/photo-1920.jpg", width: 1920, height: 1440 },
     ],
   }

   If generating multiple sizes isn't an option, a single resize to something reasonable (~1920 px on the long edge) still goes a long way.

   As a side note, many Android GPUs cap texture size at 4096 px, so 4000 px wide originals sit right at that limit.

   Either way, avoid serving JPEGs straight from a phone camera — at the very least, re-encode them. Depending on the device, camera originals often come out as progressive JPEGs with EXIF rotation metadata, and Chromium has known rendering bugs with such images when they are scaled via CSS transforms (which is how the lightbox animates and zooms). See #383, where unmodified phone photos produced visible grid-line artifacts in Chrome, and simply re-encoding the same images at the same resolution made the artifacts disappear. Any processing step — resizing with sharp, an image CDN, or even a plain re-export from a graphics editor — normalizes the encoding and sidesteps this entire class of Chromium quirks.

2. Remove the cache-busting query parameter. reproCacheBust=${Date.now()} mints a new URL on every open, so the images are re-downloaded and re-decoded from scratch each time, adding network, memory, and decode churn.

3. Hide the map while the lightbox is open — for example, set visibility: hidden on the map container when the lightbox is open. Google Maps renders on its own animation loop even when fully covered, so hiding it stops that work and releases the compositing pressure. Making the backdrop fully opaque is not enough — Maps keeps drawing regardless.

Slow image loading on iOS

This one is mostly caused by the same two factors. The cache-busting parameter means iOS Safari can never serve the images from HTTP cache, so every open re-downloads ~13 MB over the network. On top of that, iOS Safari is noticeably slower than Android Chrome at decoding very large JPEGs — it decodes lazily and applies downsampling heuristics to huge images — so a 12 MP photo shows a visible delay before it appears. There is no lightbox setting that makes a 4000×3000 JPEG decode faster on an iPhone; the fix is the same: drop the cache-buster and serve multiple image resolutions via srcSet.

One honest caveat: the flicker itself is a browser compositor behavior (Chrome on Android under GPU memory pressure), so no library can prevent it outright — but with reasonably sized images you should never come close to triggering it.

Hope this helps!

[miag676]

Thanks for the detailed explanation! Following your recommendations solved the issue.