3 ms·

Does the javascript decoder download the images, or does the browser do that, then the javascript simply decode it? If it downloads them itself, then any parall

Does the javascript decoder download the images, or does the browser do that, then the javascript simply decode it? If it downloads them itself, then any parallel fetching by browsers will stop working. And if they are decoded by javascript, they will take (very slightly) longer, and both the encoded and decoded images need to be held in memory both in javascript, and the browser. Are they decoded to .bmp, .jpg, .png? Can CSS reference them without javascript changing the styles? Can they be cached locally if downloaded directly? If you needed this for any page that loaded lots of images, all of the above would significantly increase page-load time, and memory usage. Especially on a mobile browser, it would use more resources (hence more battery), than otherwise. So personally I wouldn't like to see this be the future. Maybe just as a fall back, but detection for that might be a little hard.

Cieplak 12y ago
If you're curious how it works, untar http://bellard.org/bpg/libbpg-0.9.tar.gz http://bellard.org/bpg/libbpg-0.9.tar.gz and have a look at the post.js file.
- akshatpradhan 12y ago
  I'm a designer, can't read code, and I'm trying to see if I should evangelize this at work. Its better if you could communicate with us non-technical folk and post an answer that the previous guy asked so that we other designers can also understand.
  - k__ 12y ago
    it waits till the page is loaded (window.onload) grabs all image urls of a page checks which have .bpg extensions replaces all these .bpg img tags with canvas tags loads all the images with Ajax and renders them into the canvas tags
  - unsigner 12y ago
    If you're a designer, and don't understand the issues involved, you probably should refrain from evangelizing sub-1.0 versioned products.
    - akshatpradhan 12y ago
      Sounds like a plan. I don't need to be an early adopter
simcop2387 12y ago
A quick glance makes it look like it grabs it by url in the decoder so I think it is doing another download. That said it's probably not too bad since the browser should cache the image also.
makewavesnotwar 12y ago
>> Does the javascript decoder download the images, or does the browser do that, then the javascript simply decode it? Right now, it would appear that the with a hard reload of the demo: http://bellard.org/bpg/lena.html http://bellard.org/bpg/lena.html on chromium, the BPG images are initially loaded with the page, then the posts.js file scans through the page's images to find the ones who's src ends in '.bpg', then posts.js re-downloads the same files with ajax, which are then decoded to PNG files rendered in canvas tags with no identifying information. The extra request to re-download images is unnecessary but easily removed to just process the data loaded with the initial page load. >> Can CSS reference them without javascript changing the styles? Not from what I can see. The images are being rendered to canvas elements without any identifying information. The decoder will need to be modified to add identifying id's or classes. This again is an easy fix. >> Can they be cached locally if downloaded directly? This is what I perceive to be an issue. Try downloading the image rendered to the 5kb bpg example... The image that is being rendered is a 427.5kb PNG and that's for a 512x512 image size. PNGs aren't lossy... so any difference in file size is going to be the product of rendering size or how much the bpg compression has simplified the source image. ( I'm guessing the file size follows something like a logarithmic curve where it jumps initially based on rendered image dimensions and then approaches a limit as the compression approaches lossless. ) Because of the rendered out PNGs' large file size, I would expect that if you are rendering out large images or a lot of images, you would definitely use more resources than with comparable quality JPGs regardless of whether you cache the BPGs for rendering and you would indeed experience the drawbacks you mentioned in both memory and page-load time. That being said, this is a cool idea, an incredible proof of concept and I'm very thankful to Fabrice for putting it out there.
- cientifico 12y ago
  >> The extra request to re-download images is unnecessary but easily removed to just process the data loaded with the initial page load. Are you sure you are not inspecting with the cache disabled. If the appropriate cache headers are applied, this shouldn't issue another request.

Cieplak 12y ago

If you're curious how it works, untar http://bellard.org/bpg/libbpg-0.9.tar.gz http://bellard.org/bpg/libbpg-0.9.tar.gz and have a look at the post.js file.

akshatpradhan 12y ago
I'm a designer, can't read code, and I'm trying to see if I should evangelize this at work. Its better if you could communicate with us non-technical folk and post an answer that the previous guy asked so that we other designers can also understand.
- k__ 12y ago
  it waits till the page is loaded (window.onload) grabs all image urls of a page checks which have .bpg extensions replaces all these .bpg img tags with canvas tags loads all the images with Ajax and renders them into the canvas tags
- unsigner 12y ago
  If you're a designer, and don't understand the issues involved, you probably should refrain from evangelizing sub-1.0 versioned products.
  - akshatpradhan 12y ago
    Sounds like a plan. I don't need to be an early adopter

simcop2387 12y ago

A quick glance makes it look like it grabs it by url in the decoder so I think it is doing another download. That said it's probably not too bad since the browser should cache the image also.

makewavesnotwar 12y ago

>> Does the javascript decoder download the images, or does the browser do that, then the javascript simply decode it? Right now, it would appear that the with a hard reload of the demo: http://bellard.org/bpg/lena.html http://bellard.org/bpg/lena.html on chromium, the BPG images are initially loaded with the page, then the posts.js file scans through the page's images to find the ones who's src ends in '.bpg', then posts.js re-downloads the same files with ajax, which are then decoded to PNG files rendered in canvas tags with no identifying information. The extra request to re-download images is unnecessary but easily removed to just process the data loaded with the initial page load. >> Can CSS reference them without javascript changing the styles? Not from what I can see. The images are being rendered to canvas elements without any identifying information. The decoder will need to be modified to add identifying id's or classes. This again is an easy fix. >> Can they be cached locally if downloaded directly? This is what I perceive to be an issue. Try downloading the image rendered to the 5kb bpg example... The image that is being rendered is a 427.5kb PNG and that's for a 512x512 image size. PNGs aren't lossy... so any difference in file size is going to be the product of rendering size or how much the bpg compression has simplified the source image. ( I'm guessing the file size follows something like a logarithmic curve where it jumps initially based on rendered image dimensions and then approaches a limit as the compression approaches lossless. ) Because of the rendered out PNGs' large file size, I would expect that if you are rendering out large images or a lot of images, you would definitely use more resources than with comparable quality JPGs regardless of whether you cache the BPGs for rendering and you would indeed experience the drawbacks you mentioned in both memory and page-load time. That being said, this is a cool idea, an incredible proof of concept and I'm very thankful to Fabrice for putting it out there.

cientifico 12y ago
>> The extra request to re-download images is unnecessary but easily removed to just process the data loaded with the initial page load. Are you sure you are not inspecting with the cache disabled. If the appropriate cache headers are applied, this shouldn't issue another request.