User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1) Gecko/2008072310 Shiretoko/3.1a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1) Gecko/2008072310 Shiretoko/3.1a1 The previews contain JPG artifacts, you can't see them too much unless you change resolution to 800x600. However, they are still visible at most resolutions. Reproducible: Always Steps to Reproduce: 1. 2. 3.
> + var data = thumbnail.toDataURL("image/jpeg", "quality=60"); Is it very costly to use toDataURL("image/png", "") instead?
Yah, from what I've noticed the images also appear a SLIGHTLY delayed - so maybe this is a tradeoff for the images not appearing REALLY late after you load the page....
Encoding PNGs takes longer, I think, and is more data to cache. I did a benchmark comparing various jpeg quality settings and png. I'll try to find that data or regather it.
I'm somewhat curious as to the effect on slower PC's and/or dialup.
Bug 444898 comment 4 has a very basic benchmark.
(In reply to comment #5) > Bug 444898 comment 4 has a very basic benchmark. > While PNG does incur a higher cost than JPEG in memory (and apparently in CPU as well), you have to keep in mind that we are not encoding a full-resolution screenshot, and that the images that we are encoding are very low in resolution. As a result, I think that whatever extra cost we incur for using PNG will dwarf in comparison with other costs, such as that of resizing the image (which is rather expensive). When I get some more time, I could set up a proper benchmark to measure this, but anecdotal evidence from using the browser for a few days on my old circa-2001 laptop (800MHz Celeron) with the mode set to PNG suggests that there is no perceptible difference in performance. On this old machine, there are lags (with high CPU usage) when opening the Ctrl-Tab panel and when the tabs are cycled, but the lag is similar with both PNG and JPEG/60 (which may suggest that the difference in cost between the two formats is trivial when compared to the other costs that we have to deal with).
I think JPEG/92 would be a good trade-off. We try to create the previews beforehand -- if you're lucky, there's no delay when opening the panel. But the extra cost is still there somewhere in the background while browsing. My old benchmark didn't include the resizing. Whoever does a new one should take this into account in order to see if the encoding cost is negligible.
(In reply to comment #7) > I think JPEG/92 would be a good trade-off. > I'd personally prefer PNG. JPEG is a lossy format, so there will always be compression artifacts, no matter what quality you use. But we should probably do some benchmarks first before deciding.
bug 456088 will fix this
Verified with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081105 Minefield/3.1b2pre ID:20081105020338 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081105 Minefield/3.1b2pre