4 ms·
I tried porting VP8, but the spec is huge (the allegedly incomplete bitstream specification is 104 pages), and performance-wise, it couldn't compare to a native
by antimatter15 16y ago
I tried porting VP8, but the spec is huge (the allegedly incomplete bitstream specification is 104 pages), and performance-wise, it couldn't compare to a native webm/vp8 implementation. I guess i'll give it another shot.
I'm not exactly sure how much of vp8 is part of the interframe prediction, because WebP only contains a single intraframe, it might be practical to implement a small subset.
- user24 16y agohow about a serverside implementation? Try loading native webp, if that fails, send the webp data to a webp-to-png service and render in png on the client. Performance would probably be fine, and imagemagick or something similar will probably support webp soon so the server won't require us to write a whole webp implementation.
- antimatter15 16y agoThat negates the purpose of a bandwidth-efficient lossy image format.
- user24 16y agoeven my original idea would require a double-hit to the server, because I don't think you can extract data loaded into an image element through JS, so you'd have to read the src attribute and re-request it via XHR as raw data, and then parse that into a replacement canvas element. The main benefit is being able to default to webp, and save all your resources in that format alone, and provide a fallback for browsers which don't support it, instead of having to provide 2 sets of images and serve different ones depending on the browser.
- seanalltogether 16y agoOh believe me I'm not knocking you for having NOT done it, as I can't imagine how much work it would take to write a valid WebP parser in javascript.