4 ms·
Will it necessarily matter though? In a WASM context format starts to matter less since content in arbitrary codecs can be downloaded and decoded. There are so
by yarg 6y ago
Will it necessarily matter though?
In a WASM context format starts to matter less since content in arbitrary codecs can be downloaded and decoded.
There are some concerns:
Non-native support requires non-static pages - even for something that will always appear to be the same, things like noscript will kill the page;
Hardware acceleration will need to be done in general terms - something like WebGPU will help, but it will still be less efficient than hardware acceleration (and that could be a problem for mobile).
- gigel82 6y agoAlso CORS: you can hotlink images from everywhere, but if you try to actually put those bits in a Buffer (as you'd need with BPG) the browser won't let you unless CORS is properly set up for the specific source-target URLs (affects things like image CDNs and so on).
- wmf 6y agoChrome and Firefox are already implementing AVIF so using WASM to decode a different, more-patented format seems pointless.
- tambourine_man 6y agoHardware acceleration, as you mentioned, will never be as efficient. Besides, do you really want to download and parse a codec for every page?
- yarg 6y agoNo, not for every page - it will very much be use case dependent. However, it does present a viable path to the introduction of new codecs independent of the bogged up process that still has us using GIF and JPEG despite the fact that they've been known for years to be shite. Also, WASM supports a binary form, so you can skip parsing.
- untog 6y agoIt would mean that image decoding can’t start until the page JS is initialised, which is a pretty crappy trade off compared to today.
- mumblerino 6y agoThe point of using a format over another, given the availability, is to gain performance. You're suggesting to load a whole new parser, parse images at a higher level than browsers can (i.e. slower and with less concurrency), and make `<img>` a whole lot harder to manage. That's not worth it at all unless the savings are substantial (say BMP vs JPEG)
- tjoff 6y agoThe web we got today are an astounding feat of not caring about performance in the most aggressive way imaginable. Performance is not a factor in this.
- raindeer3 6y ago> The web we got today are an astounding feat of not caring about performance in the most aggressive way imaginable. > Performance is not a factor in this. If you care about SEO, it does. Check Google's pagespeed test.
- tjoff 6y agoIf that is true then the web does not care about SEO. And quite obviously it isn't weighted particularly hard at all (probably because there wouldn't be anything left). edit: Case in point, except for google.com (which itself has a terrible score of 62) I can't even find out a single google service that isn't in the reds on the pagespeed index. Even when it decided to load the mobile version.
- mumblerino 6y ago> Performance is not a factor in this. What a completely ridiculous statement. Why else would anyone choose BGP if not for performance (i.e. download speed)? The choice to use BGP over a plain old JPG would be made specifically by people who do care.
- tjoff 6y agoThe context here is rendering performance.