In Gecko, we will only decode images on the main thread: (1) If they’re very small and this is the first time we’re decoding them and our heuristics suggest that decoding them quickly is important. (2) If it’s absolutely required because of a synchronous API, e.g. canvas.drawImage.
We’ve been gradually tightening the rules that will trigger case 1, and in the long term I think it’s quite likely that we’ll get rid of it totally. We just need to make sure we don’t regress the user experience by doing so. Case 2 cannot be totally avoided, though it should be possible to be clever about it and defer the work in some circumstances. That’s something I hope to investigate in the future, but we’re not there yet. - Seth > On Feb 23, 2015, at 4:47 PM, say...@gmail.com wrote: > > On Thursday, 19 February 2015 18:27:48 UTC-8, Robert O'Callahan wrote: >> Last week in Sydney I spent a lot of time talking to Chrome devs about >> different approaches for 60fps effects in Web pages. > > One complaint I see that is pretty common: image decoding on the main thread > in WebKit. I don't remember how this works in Gecko, but it's definitely > enough to blow the 15ms budget while scrolling. It also bumps into various > image-discarding strategies that are done in order to save memory. > > - Rob > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
