JPEG XL

decode speed measurement

_wb_

	_wb_ https://sneyers.info/browserspeedtest/multi.html
2022-12-09 12:46:09
2022-12-09 12:46:10	let's stop posting timing results in the main channel and put them here instead
2022-12-09 12:46:47	this is what I get on firefox: s.jpg: Decode speed: 121.18 MP/s \| Fetch: 2.00ms \| 500 decodes: 1352.00ms s.jxl: Decode speed: 44.74 MP/s \| Fetch: 2.00ms \| 500 decodes: 3662.00ms s-fd3.jxl: Decode speed: 53.58 MP/s \| Fetch: 2.00ms \| 500 decodes: 3058.00ms s8.avif: Decode speed: 34.82 MP/s \| Fetch: 3.00ms \| 500 decodes: 4706.00ms s10.avif: Decode speed: 29.82 MP/s \| Fetch: 3.00ms \| 500 decodes: 5495.00ms s12.avif: Decode speed: 28.46 MP/s \| Fetch: 2.00ms \| 500 decodes: 5756.00ms s.webp: Decode speed: 68.01 MP/s \| Fetch: 2.00ms \| 500 decodes: 2409.00ms
2022-12-09 12:47:34	this is what I get on chrome: s.jpg: Decode speed: 87.26 MP/s \| Fetch: 5.10ms \| 500 decodes: 1877.50ms s.jxl: Decode speed: 62.97 MP/s \| Fetch: 4.80ms \| 500 decodes: 2601.70ms s-fd3.jxl: Decode speed: 66.00 MP/s \| Fetch: 4.60ms \| 500 decodes: 2482.30ms s8.avif: Decode speed: 67.34 MP/s \| Fetch: 5.00ms \| 500 decodes: 2433.00ms s10.avif: Decode speed: 71.64 MP/s \| Fetch: 5.40ms \| 500 decodes: 2287.10ms s12.avif: Decode speed: 68.90 MP/s \| Fetch: 4.50ms \| 500 decodes: 2378.10ms s.webp: Decode speed: 407.56 MP/s \| Fetch: 4.10ms \| 500 decodes: 402.00ms especially for webp the difference is very big, I wonder what is going on there
2022-12-09 12:47:37	On my phone, I get this on chrome: s.jpg: Decode speed: 11.54 MP/s \| Fetch: 133.80ms \| 500 decodes: 14203.20ms s.jxl: Decode speed: 8.72 MP/s \| Fetch: 185.00ms \| 500 decodes: 18779.40ms s-fd3.jxl: Decode speed: 9.56 MP/s \| Fetch: 194.20ms \| 500 decodes: 17137.00ms s8.avif: Decode speed: 11.20 MP/s \| Fetch: 120.20ms \| 500 decodes: 14629.10ms s10.avif: Decode speed: 11.50 MP/s \| Fetch: 183.00ms \| 500 decodes: 14243.90ms s12.avif: Decode speed: 10.87 MP/s \| Fetch: 114.10ms \| 500 decodes: 15066.70ms s.webp: Decode speed: 78.87 MP/s \| Fetch: 179.50ms \| 500 decodes: 2077.40ms
2022-12-09 12:47:51	And this on firefox nightly: s.jpg: Decode speed: 67.31 MP/s \| Fetch: 211.00ms \| 500 decodes: 2434.00ms s.jxl: Decode speed: 9.79 MP/s \| Fetch: 190.00ms \| 500 decodes: 16738.00ms s-fd3.jxl: Decode speed: 11.33 MP/s \| Fetch: 169.00ms \| 500 decodes: 14465.00ms s8.avif: Decode speed: 14.77 MP/s \| Fetch: 236.00ms \| 500 decodes: 11091.00ms s10.avif: Decode speed: 12.78 MP/s \| Fetch: 238.00ms \| 500 decodes: 12816.00ms s12.avif: Decode speed: 11.53 MP/s \| Fetch: 2254.00ms \| 500 decodes: 14213.00ms s.webp: Decode speed: 37.10 MP/s \| Fetch: 2373.00ms \| 500 decodes: 4416.00ms
2022-12-09 12:48:51	Something weird is going on with those webp timings, also jpeg is kind of slow on chrome
2022-12-09 12:52:19	this is what I get on my laptop

Sauerstoffdioxid

2022-12-09 12:54:10	Firefox nightly on my phone (Helio P25 SoC, Android 7.1.1): s.jpg: Decode speed: 41.83 MP/s \| Fetch: 55.00ms \| 500 decodes: 3917.00ms s.webp: Decode speed: 22.94 MP/s \| Fetch: 48.00ms \| 500 decodes: 7143.00ms s.jxl: Decode speed: 6.38 MP/s \| Fetch: 43.00ms \| 500 decodes: 25698.00ms s8.avif: Decode speed: 8.86 MP/s \| Fetch: 36.00ms \| 500 decodes: 18484.00ms s12.avif: Decode speed: 6.27 MP/s \| Fetch: 96.00ms \| 500 decodes: 26136.00ms
2022-12-09 12:56:26	(Chrome results will take a hot second)
2022-12-09 01:00:57	Chrome 108 on that same phone s.jpg: Decode speed: 5.37 MP/s \| Fetch: 191.80ms \| 500 decodes: 30507.70ms s.webp: Decode speed: 59.31 MP/s \| Fetch: 249.30ms \| 500 decodes: 2762.40ms s.jxl: Decode speed: 5.51 MP/s \| Fetch: 290.30ms \| 500 decodes: 29733.20ms s8.avif: Decode speed: 5.50 MP/s \| Fetch: 213.60ms \| 500 decodes: 29788.20ms s12.avif: Decode speed: 5.62 MP/s \| Fetch: 220.90ms \| 500 decodes: 29175.20ms s-fd3.jxl: Decode speed: 5.63 MP/s \| Fetch: 454.80ms \| 500 decodes: 29094.40ms
2022-12-09 01:02:08	Surprisingly, classic JPEG is the slowest out of these. So I guess it's bottlenecking somewhere else.

_wb_

2022-12-09 01:04:01	yes, those jpeg/webp results on chrome seem weird...
2022-12-09 01:06:32	anyway, I think it's fair to say that jxl and avif decode speed is "roughly the same"

Sauerstoffdioxid

2022-12-09 01:08:21	Yeah, at least on Firefox that seems to be the case even on my crappy phone. For completeness sake, I've also run it on my desktop (Ryzen 5600G) with Firefox nightly: s.jpg: Decode speed: 153.26 MP/s \| Fetch: 165.00ms \| 500 decodes: 1069.00ms s.jxl: Decode speed: 47.43 MP/s \| Fetch: 257.00ms \| 500 decodes: 3454.00ms s-fd1.jxl: Decode speed: 50.40 MP/s \| Fetch: 167.00ms \| 500 decodes: 3251.00ms s-fd2.jxl: Decode speed: 50.91 MP/s \| Fetch: 234.00ms \| 500 decodes: 3218.00ms s-fd3.jxl: Decode speed: 54.67 MP/s \| Fetch: 183.00ms \| 500 decodes: 2997.00ms s8.avif: Decode speed: 41.50 MP/s \| Fetch: 238.00ms \| 500 decodes: 3948.00ms s10.avif: Decode speed: 37.17 MP/s \| Fetch: 641.00ms \| 500 decodes: 4408.00ms s12.avif: Decode speed: 35.42 MP/s \| Fetch: 200.00ms \| 500 decodes: 4625.00ms s.webp: Decode speed: 92.88 MP/s \| Fetch: 157.00ms \| 500 decodes: 1764.00ms
2022-12-09 02:15:21	I noticed something about the multi-test. The function `createImageBitmap` is async. That means, it's execution is added to some pool and done in the background while the JS main thread continues its execution. Thus, the 500 decodes loop finishes before the first image is even fully decoded. On Firefox this doesn't seem to change anything, as those background threads appear to be executed in order. However on Chrome, they are worked on in parallel. This can be considered both good and bad, I believe. On one hand, it shows that JXL really can be just as fast as AVIF, given enough threads. On the other hand, Chrome can finish execution before the last image is fully decoded, ~~and it works around its JXL integration being single threaded.~~ Edit: Actually it seems both avif and jxl receive the same processing resources. 🤔 At least, according to my task manager, which might not be super accurate. But the cpu load graph seems quite similar between the two.
2022-12-09 02:17:08	If I force it to execute sequentially, I get these numbers on Chrome: s.jxl: Decode speed: 22.51 MP/s \| Fetch: 5.60ms \| 500 decodes: 7277.00ms s8.avif: Decode speed: 27.45 MP/s \| Fetch: 6.40ms \| 500 decodes: 5968.10ms s12.avif: Decode speed: 22.57 MP/s \| Fetch: 6.40ms \| 500 decodes: 7260.50ms
2022-12-09 02:20:47	To make it decode sequentially, the `decodeImage` function needs to be changed to something like this: ```javascript async function decodeImage(blob, mimetype) { imageDecodeStart = performance.now(); fetchingMilli = imageDecodeStart - startMilli; for (let i = 0; i < iterations-1;i++) { await createImageBitmap(blob) } createImageBitmap(blob).then(renderImage); }``` (notice the async in the function definition, and the await before the `createImageBitmap`)
2022-12-09 02:29:44	With that change, webp is still faster than jpeg, but not by quite as much s.jpg: Decode speed: 61.14 MP/s \| Fetch: 6.40ms \| 500 decodes: 2679.90ms s.webp: Decode speed: 79.34 MP/s \| Fetch: 8.10ms \| 500 decodes: 2065.00ms
2022-12-09 03:17:27	Some sequential decode numbers from mobile Chrome s.jxl: Decode speed: 1.01 MP/s \| Fetch: 15.00ms \| 500 decodes: 161777.90ms s8.avif: Decode speed: 2.65 MP/s \| Fetch: 27.20ms \| 500 decodes: 61772.40ms s12.avif: Decode speed: 2.07 MP/s \| Fetch: 38.40ms \| 500 decodes: 79217.10ms s.webp: Decode speed: 20.10 MP/s \| Fetch: 16.10ms \| 500 decodes: 8151.90ms s.jpg: Decode speed: 5.44 MP/s \| Fetch: 14.60ms \| 500 decodes: 30139.70ms

_wb_

2022-12-09 03:52:49

Ah, thanks for the explanation, I already suspected something like that might have been going on. Is there a way to keep the async/parallel decode (which I think is more fair), but ensure that the time for doing all 500 decodes is measured?

Sauerstoffdioxid

2022-12-09 04:26:56

I believe this should do the trick: ```javascript function decodeImage(blob, mimetype) { imageDecodeStart = performance.now(); fetchingMilli = imageDecodeStart - startMilli; let completedDecodes = 0; for (let i = 0; i < iterations; i++) { createImageBitmap(blob).then(decoded => { if (++completedDecodes == iterations) { renderImage(decoded); } }); } }```

username

2022-12-10 04:14:38

_wb_

2022-12-10 10:03:50	https://sneyers.info/browserspeedtest/ fixed it to ensure all iterations are actually done
2022-12-10 10:04:14	webp still is fast and jpeg slow on chrome...

Sauerstoffdioxid

2022-12-10 01:22:56	fwiw, I tried making a parallel decode test using Chrome's `ImageDecoder` API used in the original benchmark. My reasoning is that that api might not show the same issues with jpeg and webp that `createImageBitmap` is showing. I kinda got something working, but it likes to crash the chrome tab. AVIF >10 bit is especially crash-prone. I'll try to get a complete set of numbers
2022-12-10 01:31:56	s.jpg: Decode speed: 2892.14 MP/s \| Fetch: 3.30ms \| 1000 decodes: 113.30ms \| Format: I420 s.jxl: Decode speed: 216.46 MP/s \| Fetch: 4.10ms \| 1000 decodes: 1513.80ms \| Format: BGRX s-fd1.jxl: Decode speed: 219.89 MP/s \| Fetch: 11.00ms \| 1000 decodes: 1490.20ms \| Format: BGRX s-fd2.jxl: Decode speed: 223.60 MP/s \| Fetch: 10.90ms \| 1000 decodes: 1465.50ms \| Format: BGRX s-fd3.jxl: Decode speed: 252.49 MP/s \| Fetch: 11.20ms \| 1000 decodes: 1297.80ms \| Format: BGRX s8.avif: Decode speed: 366.90 MP/s \| Fetch: 11.00ms \| 1000 decodes: 893.10ms \| Format: I444 s10.avif: Decode speed: 299.83 MP/s \| Fetch: 4.20ms \| 1000 decodes: 1092.90ms \| Format: BGRX s12.avif: Decode speed: 252.80 MP/s \| Fetch: 11.00ms \| 1000 decodes: 1296.20ms \| Format: BGRX s.webp: Decode speed: 810.69 MP/s \| Fetch: 11.00ms \| 1000 decodes: 404.20ms \| Format: I420
2022-12-10 01:33:46	For reference, this is Chrome version 108.0.5359.98 on a Ryzen 5600G Linux desktop PC
2022-12-10 01:40:25	I also adjusted the way the threading works, but it doesn't appear to make any difference on Firefox. It's essentially the same as previously. (It still falls back to createImageBitmap for browsers that don't have ImageDecoder) s.jpg: Decode speed: 149.90 MP/s \| Fetch: 10.00ms \| 1000 decodes: 2186.00ms s.jxl: Decode speed: 47.35 MP/s \| Fetch: 5.00ms \| 1000 decodes: 6921.00ms s-fd1.jxl: Decode speed: 48.86 MP/s \| Fetch: 12.00ms \| 1000 decodes: 6706.00ms s-fd2.jxl: Decode speed: 48.85 MP/s \| Fetch: 12.00ms \| 1000 decodes: 6708.00ms s-fd3.jxl: Decode speed: 51.77 MP/s \| Fetch: 13.00ms \| 1000 decodes: 6329.00ms s8.avif: Decode speed: 41.31 MP/s \| Fetch: 13.00ms \| 1000 decodes: 7932.00ms s10.avif: Decode speed: 37.99 MP/s \| Fetch: 12.00ms \| 1000 decodes: 8625.00ms s12.avif: Decode speed: 35.69 MP/s \| Fetch: 12.00ms \| 1000 decodes: 9180.00ms s.webp: Decode speed: 93.22 MP/s \| Fetch: 12.00ms \| 1000 decodes: 3515.00ms
2022-12-10 02:00:03	The file if you're curious

_wb_

2022-12-11 02:29:21	https://sneyers.info/browserspeedtest/
2022-12-11 02:29:26	I updated the webp file
2022-12-11 02:29:49	cwebp doesn't copy the icc profile so it had wrong colors due to that
2022-12-11 02:30:01	adding the icc profile makes webp slower
2022-12-11 02:30:17	so I guess a bit part of these decode speeds are actually color management
2022-12-11 02:30:34	https://sneyers.info/browserspeedtest/index2.html
2022-12-11 02:30:46	I tried a different image that is just untagged, so sRGB
2022-12-11 02:34:20	I expected this to be faster since the html canvas is also supposed to be sRGB so there should be no color conversion needed at all here
2022-12-11 02:34:56	but I now get weird results
2022-12-11 02:36:11	011.jpg: Decode speed: 134.90 MP/s \| Fetch: 28.00ms \| 100 decodes: 242.90ms 011.jpg.jxl: Decode speed: 66.86 MP/s \| Fetch: 287.10ms \| 100 decodes: 490.10ms 011.jxl: Decode speed: 40.65 MP/s \| Fetch: 4.30ms \| 100 decodes: 806.10ms 011-fd1.jxl: Decode speed: 42.98 MP/s \| Fetch: 188.30ms \| 100 decodes: 762.40ms 011-fd2.jxl: Decode speed: 44.19 MP/s \| Fetch: 187.80ms \| 100 decodes: 741.50ms 011-fd3.jxl: Decode speed: 50.46 MP/s \| Fetch: 175.80ms \| 100 decodes: 649.40ms 011-8bit420.avif: Decode speed: 86.03 MP/s \| Fetch: 172.50ms \| 100 decodes: 380.90ms 011-8bit444.avif: Decode speed: 2.92 MP/s \| Fetch: 184.90ms \| 100 decodes: 11212.50ms 011-10bit.avif: Decode speed: 2.88 MP/s \| Fetch: 183.50ms \| 100 decodes: 11395.40ms 011-12bit.avif: Decode speed: 2.85 MP/s \| Fetch: 181.80ms \| 100 decodes: 11516.40ms 011.webp: Decode speed: 115.99 MP/s \| Fetch: 440.90ms \| 100 decodes: 282.50ms
2022-12-11 02:38:52	somehow the jxl speed goes down on this image (I was getting > 60 MP/s on the other image), the 8-bit yuv420 avif speed goes up, and in all the other avif cases, the speed goes down like crazy for some reason
2022-12-11 02:40:06	that's in chrome
2022-12-11 02:40:10	in firefox, I get this: 011.jpg: Decode speed: 36.61 MP/s \| Fetch: 103.00ms \| 100 decodes: 895.00ms 011.jpg.jxl: Decode speed: 26.11 MP/s \| Fetch: 167.00ms \| 100 decodes: 1255.00ms 011.jxl: Decode speed: 16.91 MP/s \| Fetch: 209.00ms \| 100 decodes: 1938.00ms 011-fd1.jxl: Decode speed: 18.45 MP/s \| Fetch: 186.00ms \| 100 decodes: 1776.00ms 011-fd2.jxl: Decode speed: 19.10 MP/s \| Fetch: 257.00ms \| 100 decodes: 1716.00ms 011-fd3.jxl: Decode speed: 20.18 MP/s \| Fetch: 231.00ms \| 100 decodes: 1624.00ms 011-8bit420.avif: Decode speed: 13.10 MP/s \| Fetch: 190.00ms \| 100 decodes: 2502.00ms 011-8bit444.avif: Decode speed: 12.83 MP/s \| Fetch: 225.00ms \| 100 decodes: 2555.00ms 011-10bit.avif: Decode speed: 10.56 MP/s \| Fetch: 185.00ms \| 100 decodes: 3104.00ms 011-12bit.avif: Decode speed: 8.93 MP/s \| Fetch: 201.00ms \| 100 decodes: 3668.00ms 011.webp: Decode speed: 21.35 MP/s \| Fetch: 186.00ms \| 100 decodes: 1535.00ms
2022-12-11 02:47:48	no idea what is going on here, but looks like there is quite a bit of an image-dependent element in the decode speed.
2022-12-11 02:48:34	Looks like sRGB yuv420 avif is very well optimized, but for some reason sRGB yuv444 avif is horribly slow on chrome?

afed

2022-12-11 04:08:03

2022-12-11 04:09:23

Info

JPEG XL

General chat

Voice Channels

Archived

decode speed measurement