3 ms·

Looks pretty interesting, I wonder it the result produced by WUFFS transpiled code could be used as drop-in replacement Of course the issue with transpiled cod

by dvhh 3y ago

Looks pretty interesting, I wonder it the result produced by WUFFS transpiled code could be used as drop-in replacement Of course the issue with transpiled code ( same for generated code ), is that is making debugging a lot more difficult.

tialaramex 3y ago
Chrome's GIF rendering is already WUFFS, but no, this would not be a "drop-in" replacement because it needs glue. I assume the GIF decoding has glue but you can't "just" reuse it.
- lifthrasiir 3y ago
  Wait, really? (Searches) Oh indeed [1]. I should note that the glue code is more than 1000 lines of C++ though. Still glad to see that it got into the production. [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/skia/src/codec/SkWuffsCodec.cpp https://source.chromium.org/chromium/chromium/src/+/main:thi...
  - nigeltao 3y ago
    Wuffs and SkWuffsCodec.cpp author here. Wuffs' GIF decoder has shipped in Google Chrome since July 2021 (milestone M93). A fair chunk out of that 1000 lines of glue code is adapting Wuffs' API to Skia's API. (Skia is the 2-D graphics library used by Chromium and many other projects). Specifically, GIFs can be animated, Wuffs' animation API is designed for sequential access and its state needs O(1) memory but Skia's SkCodec animation API allows random access and needs O(N) memory, where N is the number of animation frames. Random access means that, after decoding frame 100, the SkCodec can rewind and produce frame 70 (by scanning backwards through its O(N) state to find the most recent I-Frame equivalent that's <= 70 and replaying forward from there). Random access seems a bit of a weird feature to me, but Chrome/Skia's old GIF codec could do it, for whatever historical reasons, so the new Wuffs-backed one does too (even though it needed a chunk of glue code).
- dvhh 3y ago
  As pointed out by another commenter, WUFFS would not itself allocate memory, which is fine, but would need some additional help to perform that task

by dvhh 3y ago

tialaramex 3y ago

Chrome's GIF rendering is already WUFFS, but no, this would not be a "drop-in" replacement because it needs glue. I assume the GIF decoding has glue but you can't "just" reuse it.

lifthrasiir 3y ago
Wait, really? (Searches) Oh indeed [1]. I should note that the glue code is more than 1000 lines of C++ though. Still glad to see that it got into the production. [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/skia/src/codec/SkWuffsCodec.cpp https://source.chromium.org/chromium/chromium/src/+/main:thi...
- nigeltao 3y ago
  Wuffs and SkWuffsCodec.cpp author here. Wuffs' GIF decoder has shipped in Google Chrome since July 2021 (milestone M93). A fair chunk out of that 1000 lines of glue code is adapting Wuffs' API to Skia's API. (Skia is the 2-D graphics library used by Chromium and many other projects). Specifically, GIFs can be animated, Wuffs' animation API is designed for sequential access and its state needs O(1) memory but Skia's SkCodec animation API allows random access and needs O(N) memory, where N is the number of animation frames. Random access means that, after decoding frame 100, the SkCodec can rewind and produce frame 70 (by scanning backwards through its O(N) state to find the most recent I-Frame equivalent that's <= 70 and replaying forward from there). Random access seems a bit of a weird feature to me, but Chrome/Skia's old GIF codec could do it, for whatever historical reasons, so the new Wuffs-backed one does too (even though it needed a chunk of glue code).
dvhh 3y ago
As pointed out by another commenter, WUFFS would not itself allocate memory, which is fine, but would need some additional help to perform that task