5 ms·

It says very clearly a number of times that it's better in terms of compression ratio.

by dave2000 11y ago

teh_klev 11y ago
It says: "Encoding and decoding speeds are acceptable, but should be improved" But that doesn't address resource usage such as CPU, battery.
- dalke 11y ago
  It's hard for a single author/developer to fully explore solution space. For example, it could be that Javascript acquires special primitives to decode these images, or that they be a common Javascript engine extension, with a polyfill fallback. It could be that these extensions make effective use of CPU-specific instructions, or that the underlying hardware contains special silicon to decode these images, similar to how there are H.264 decoder chips. It's therefore possible to do the power consumption analysis, but the results would not really indicate something fundamental about the algorithm but only its current implementation. People are willing to work on improved implementations if there are other factors, like smaller size, which suggest it's worthwhile to investigate.
  - teh_klev 11y ago
    Appreciate the time spent answering this.
formula1 11y ago
Reason why your downvoted is because compression can often add to computation. An exanple would be - I have a pallet of bytes, this will cause colors to be stored in a 8 bit integer instead of a 32 bit one (8 for r,b,g,a) - every color now adds alook up to that memory address - I turn every color sequence possible into a numerator + denominator pair < 256 when possible. I add a length and offset to define how to compute it - when you reach a sequence, you must calculate the number. Find the offset (up to 256) and until the length (ideally > than 4 bytes) is reached get the value of that digit. These types of calculations seem small, and likely are more often than not. But you add enough of these things up and all of a sudden the cpu must hit 100% for the time of 30+ images
- dave2000 11y ago
  I don't care about my score. I could have guessed why though. People not reading things properly. I was taking point with the observation that the site said it was better. I pointed out that it didn't say that, just that the compression ratio was better.
  - teh_klev 11y ago
    > People not reading things properly I did read the article twice and thoroughly, all I sawmentioned was "Encoding and decoding speeds are acceptable, but should be improved" . That doesn't address the points I raised in my original post if you were to read it properly.

It says very clearly a number of times that it's better in terms of compression ratio.

It says: "Encoding and decoding speeds are acceptable, but should be improved" But that doesn't address resource usage such as CPU, battery.

dalke 11y ago
It's hard for a single author/developer to fully explore solution space. For example, it could be that Javascript acquires special primitives to decode these images, or that they be a common Javascript engine extension, with a polyfill fallback. It could be that these extensions make effective use of CPU-specific instructions, or that the underlying hardware contains special silicon to decode these images, similar to how there are H.264 decoder chips. It's therefore possible to do the power consumption analysis, but the results would not really indicate something fundamental about the algorithm but only its current implementation. People are willing to work on improved implementations if there are other factors, like smaller size, which suggest it's worthwhile to investigate.
- teh_klev 11y ago
  Appreciate the time spent answering this.

formula1 11y ago

Reason why your downvoted is because compression can often add to computation. An exanple would be - I have a pallet of bytes, this will cause colors to be stored in a 8 bit integer instead of a 32 bit one (8 for r,b,g,a) - every color now adds alook up to that memory address - I turn every color sequence possible into a numerator + denominator pair < 256 when possible. I add a length and offset to define how to compute it - when you reach a sequence, you must calculate the number. Find the offset (up to 256) and until the length (ideally > than 4 bytes) is reached get the value of that digit. These types of calculations seem small, and likely are more often than not. But you add enough of these things up and all of a sudden the cpu must hit 100% for the time of 30+ images

dave2000 11y ago
I don't care about my score. I could have guessed why though. People not reading things properly. I was taking point with the observation that the site said it was better. I pointed out that it didn't say that, just that the compression ratio was better.
- teh_klev 11y ago
  > People not reading things properly I did read the article twice and thoroughly, all I sawmentioned was "Encoding and decoding speeds are acceptable, but should be improved" . That doesn't address the points I raised in my original post if you were to read it properly.