3 ms·
Impressive! Right now it requires a .js decoder, of 75kb. Assuming a fast C++ decoder instead,(possibly GPU accelerated if the decoding algorithm is well suite
by vmarsy 12y ago
Impressive! Right now it requires a .js decoder, of 75kb.
Assuming a fast C++ decoder instead,(possibly GPU accelerated if the decoding algorithm is well suited for it) and not using JS but what would be the rendering times?
PNG are 4x bigger in his experiments, but interlaced PNG makes it more pleasant to users since it can be rendered progressively, can BPG benefit from such a thing?
edit: Interlacing is also used in JPEG, isn't it ?
It's a tradeoff, as a user, it's obvisouly a win situation when we have a low bandwidth, and as a server it's obviously a win.
- TD-Linux 12y agoProgressive rendering of HEVC is not possible in the same way as it is done for JPEG or PNG. It is also not very suited to GPU rendering. A C++ decoder with assembly optimizations could easily run four times as fast as the Javascript version. Unfortunately distributing it would not be possible due to patents.
- faragon 12y agoFour times? You can expect the C/C++ version (with some SIMD intrinsics) to run 10-30x faster than the JIT-optimized JS version.
- mischanix 12y agoThere is also the overhead of using a canvas element as a render target instead of a normal image surface, and using the canvas API instead of just writing color values straight to a buffer.
- kinghajj 12y agoWhy would a C++ version have to worry about patents but the JS one does not?
- TD-Linux 12y agoThey both have to worry, just a different person. For JS, it is the page author / publisher. For C++, it would be the browser vendor.
- masklinn 12y ago> edit: Interlacing is also used in JPEG, isn't it ? Yes, and contrary to PNG it actually makes files smaller.