DEMData: save one CPU copy and do decode on GPU

[astojilj]

Save one CPU copy and avoid decoding DEM data on CPU (do it on GPU).

Pad DEMData, for backfill, in context.getImageData. This avoids the need to pad it in DEMData constructor.

DEM decode to height is a single dot operation - no need to do it on CPU since we already have another decode (from internal format) in src/shaders/hillshade_prepare.fragment.glsl.

Time spent, averaged in milliseconds, in getImageData and new DEMData is measured using this patch.

When opening debug/hillshade.html, page loads 7 256x256 tiles, with total 368ms (~52ms per tile) spent in new DEMData. This is reduced to 1 ms per tile with the patch.

                    master branch       |          with this patch
----------------------------------------|-------------------------------           
           new DEMData  | getImageData  |  new DEMData  | getImageData     
------------------------|---------------|---------------|---------------           
iPhoneX       45 ms     |     12 ms     |       1 ms    |     12 ms 

cc @mapbox/gl-native

[andrewharvey]

Oh hey it looks like this partially fixes #6027 🎉 This is awesome. If you look closely you can still see some artefacts described in #6027 with this PR, but they don't appear for a few extra zooms further than currently in master, and without more testing I can't say if that's due to a limitation in the data or in the codebase... I can help try to answer that.

Two screen shots below, exact same data and style:

master

this PR

[andrewharvey]

This performance improvement is awesome.

Though I wanted to point some tangential analysis I did a while back at mapbox/rio-rgbify#3 (comment). I know this is a bit off topic and not something that can be addressed on the client side, but might be worth investigating.

For a large map that takes 25 256x256 terrain tiles for the map, that's 3.3MB and took about 4.3 seconds just to download those tiles, this would be worse over a bad mobile connection.

Asking for terrain-rgb webp tiles, Mapbox still only serves pngs anyway.

https://a.tiles.mapbox.com/v4/mapbox.terrain-rgb/9/85/197@2x.webp
> identify 197@2x.webp
PNG 512x512 512x512+0+0 8-bit sRGB

I tried a few compression options to see what affect that would have:

> for f in tiles/*; do b=`basename $f`; pngcrush -brute $f pngcrush/$b; done
> for f in tiles/*; do b=`basename $f`; cwebp -lossless -q 100 -m 6 $f -o cwebp/$b; done

method	total size
original	3.3M
pngcrush	2.4M ~30% improvement
cwebp	1.8M ~50% improvement

Keep in mind both of these compressions are lossless, so there's big gains to be made by spending more compute on the API side to reduce the size sent over the wire.

[astojilj]

@andrewharvey

Thanks for checking #6027 and letting me know.

[ansis]

This is great! I just have that one suggestion about type checking but other than that this looks ready. Thanks