The current JPEG XL decoder in #Firefox apparently consists more than 100,000 lines of multi-threaded C++

For just decoding an image format.

Not sure what it says about the format, the implementation and the Internet at large.

https://github.com/mozilla/standards-positions/pull/1064

  • Even Rouault@mastodon.social
    link
    fedilink
    arrow-up
    4
    ·
    2 months ago

    @bagder@mastodon.social To put in perspective:

    • JPEG: libjpeg 6b encoder+decoder: 24,200 lines of C
    • JPEG: libjpeg-turbo encoder+decoder: 127,000 of C and ASM (multi architectures)
    • JPEG2000: openjpeg encoder+decoder: 50,000 lines of .C
    • JPEG2000: Kakadu commercial encoder+decoder: 214,000 lines of C++ (only coresys component)
    • libjxl: 150,000 lines for the core library, encoder+decoder (deps excluded)
      (All above includes blank lines + inline doc)
      So this is pretty much standard for a modern codec
    • Thomas Depierre@hachyderm.io
      link
      fedilink
      arrow-up
      2
      ·
      2 months ago

      @bagder (i will keep banging the drums that most of the FOSS “supply chain” fear could be handled by investing more in programming language tooling, as Rust demonstrate, and that it would be a small overall cost for massive pay off…)

      • daniel:// stenberg://@mastodon.socialOP
        link
        fedilink
        arrow-up
        1
        ·
        2 months ago

        @Di4na possibly: I believe Rust is generally a good thing for most things, but I believe the Rust ecosystem with cargo and bazillions of always-updatiing tiny dependencies risk adding friction and at least complicates the equation quite a lot

        • @bagder@mastodon.social @Di4na@hachyderm.io
          I’m not sure it is a tooling issue. I find cargo to be a great tool, and it have a lock file to let you update deps in a controlled fashion.
          I think this comes down to a cultural issue, where the rust community, much like the JS community, put every little utility function in it’s own library. Hence, you tend to get a gazillion small dependencies that is hard to keep track of.

        • mort@fosstodon.org
          link
          fedilink
          arrow-up
          1
          ·
          2 months ago

          @bagder@mastodon.social This is my biggest worry too: they essentially copied the NPM package management model and practices. Good for short term productivity, but I worry that it causes significant long-term maintainability problems.

          And everything is version 0.x, in part due to technical limitations of Cargo: moving out of 0.x is a breaking change, so if you have users on 0.x (which Cargo encourages by treating 0.x specially) moving out of 0.x breaks them.

        • Thomas Depierre@hachyderm.io
          link
          fedilink
          arrow-up
          1
          ·
          2 months ago

          @bagder@mastodon.social i mean yes, but at least the compiler is a tool.

          While C and others are uh. Well some are finally realising they have users

  • DamonHD@mastodon.social
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    2 months ago

    @bagder We had 100kloc C++ in a smart radiator valve that saved a bunch of extra energy.

    I think it is just a reflection that extracting efficiency requires complexity.

  • Walther@mastodon.social
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    2 months ago

    @bagder I think it is a bit misleading (and arguably unfair) to attribute this to Firefox specifically: this is the reference jpeg-xl implementation, originally created and maintained by Google, and in widespread experimental use across all kinds of browsers, including Chromium, Safari, Edge and more

  • Daniel@chaos.social
    link
    fedilink
    arrow-up
    1
    ·
    2 months ago

    @bagder@mastodon.social It’s a good hot take, but what amazes me most is the replies so far immediately jumping to conclusions with biased gut reactions as if their identity is tied to one or the other camp.

  • tא‎máš@witter.cz
    link
    fedilink
    arrow-up
    1
    ·
    2 months ago

    @bagder@mastodon.social Wait, so JPEG XL isn’t completely dead? That’s probably not what you meant to communicate but I’m so happy to hear that

    fwiw I think that LOC of the reference implementation doesn’t really say anything about anything - even if Firefox “adopted” it, which feels like a sensible choice given the state of things

  • David W. Jones@mastodon.social
    link
    fedilink
    arrow-up
    1
    ·
    2 months ago

    @bagder@mastodon.social
    And, just wondering:
    How many of those lines are for handling security issues such as boobytrapped JPEGs?
    How many lines do the other HTML rendering engine use for the same function?
    The graphical web has many sins to make amends for!

  • supersingular@chaos.social
    link
    fedilink
    arrow-up
    1
    ·
    2 months ago

    @bagder@mastodon.social could isolate the decoder in a WASM runtime and only starting the rewrite if and when the format becomes popular enough :-)