7 ms·

Bellard is obviously a technical genius. I have no doubt that BPG is competitive on a technical aspect. Politically though AV1 is looking like it has the best c

• 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 ago
    Also 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 ago
    Chrome and Firefox are already implementing AVIF so using WASM to decode a different, more-patented format seems pointless.
  • tambourine_man 6y ago
    Hardware 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 ago
      No, 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 ago
    It 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 ago
    The 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 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.
      • 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 ago
          If 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 ago
          The context here is rendering performance.
• ksec 6y ago
  >and patent free. Royalty Free. Purely from a Web Image usage perspective, Jpeg XL is very competitive in terms of features and performance. Also Royalty free.