The disadvantage is that each scan takes about the same amount of computation to display as a whole baseline JPEG file would.
This is only true if you're actually displaying each and every refinement level. If you only display the final image, progressive and baseline JPEG have about the same computational complexity. Progressive is still slower because of less efficient cache access patterns, however.
It really sounds like a huge blunder that the retina iPad still has those artificial webkit resource limits, preventing display of fullscreen jpegs in the native resolution.
A huge blunder or a yet-to-be tweaked nuance of the Webkit engine? Seems to me that a huge blunder would entail a very difficult to address issue. I'll chalk this up as a minor blunder.
It really seems like one of those after release patch items. Something that OS X would have in a 0.0.1 update. It is iPad 3 generation specific and they didn't do a specific release update this time so that might make it a patch item.
A simpler explanation would be that baseline JPEG is decoded in hardware that has a maximum width of 2048 or 4096, and progressive JPEG triggers a software fallback. Easy for Apple to fix, just add a check for widths larger than the hardware can handle.
5 comments
[ 5.0 ms ] story [ 5.7 ms ] threadThis is only true if you're actually displaying each and every refinement level. If you only display the final image, progressive and baseline JPEG have about the same computational complexity. Progressive is still slower because of less efficient cache access patterns, however.