Consider exposing `HTMLImageElement.decoding` for `ImageOverlay`

Motivation

Hi there! We at Mozilla see a quite a few Web Compatibility reports about various applications using an animated map layer on top of Leaflet, where the animation is flickering. For example: there’s this issue on firesmoke.ca.

The primary issue here is a bit of a race between showing and decoding the image. When image tags are hidden, browsers may not decode the image files to save on memory and performance, and they’ll defer decoding to when the image becomes visible. There are a couple of Leaflet plugins that use hiding and showing layers to achieve an animation effect, and that might result in flickering. Not just in Firefox, this could affect all browsers, and is highly dependent on the systems performance and the image decoders performance…

Suggested solution

A reliable way to solve this is to add the decoding="sync" attribute to the img tag, or to set HTMLImageElement.decoding to sync via the DOM API. This will force the browser to decode right away, which eliminates the possibility for flickering.

While I don’t think setting the decoding mode to sync by default is a good idea, I’d love this to be exposed as an option to the ImageOverlay, so that libraries could set sync on layers they know will be animated.

Alternatives considered

Sites could probably workaround that by modifying the DOM themselves, but that’s not a maintainable idea. Some sites we know of have monkey-patched Leaflet to always add the sync decoding flag, but that’ll lock them out of easy Leaflet updates, and is also not something we’d consider. Browsers could improve their logic for deciding if something should be sync or async, but that’s not easy, and I think that making the intentions clear on the image tag is a cleaner solution.

[denschub]

Note that users should be able to do something like myOverlay.getElement().decoding='sync' with the current API. getElement() exposes the HTMLImageElement itself.

Oh that’s good to know. We might be able to suggest that to site owners if they cannot update Leaflet for a reason or something!

But maybe it had other reasons

Probably, yeah. Image loading on first load vs. adding images to the DOM at a later point is a different beast. Shameless plug: if you run into issues with any specific browser, file a bug on https://webcompat.com - there’s also Safari people participating, not just us Mozilla folks! We’re happy to debug that, even if that might be something Leaflet could address (like this feature request!)

[Falke-Design]

Note that users should be able to do something like myOverlay.getElement().decoding=‘sync’ with the current API. getElement() exposes the HTMLImageElement itself.

My experience with #8633 was that changing decoding while loading didn’t take effect. But maybe it had other reasons