- From: Alexander Farkas <info@corrupt-system.de>
- Date: Sun, 05 Oct 2014 21:06:43 +0200
- To: public-respimg@w3.org
- Message-ID: <543196C3.3010500@corrupt-system.de>
I just wanted to share my new project respimages (https://github.com/aFarkas/respimage) with you. In short: It's a heavily refactored and bugfixed version of picturefill, while it has some new features and a lot of improvements. There are 2 conceptual main differences to picturefill: 1. src attribute is recommended respimages uses some image data loading best practices to compensate the problem of doubble requests in polyfilled browsers. As it turns out it's not just a compensation, it can be really a speed boost ;) 2. smarter candidate selection Due to the fact, that the polyfill is run in an unknown enviroment (unknown bandwidth, cpu, battery, user preferences and so on), I'm trying to calculate the tradeoff of loading too much image data vs. too less image data. About both things, I wrote a little bit more, which you can find here: https://github.com/aFarkas/respimage/blob/stable/how-respimg-works.md Additionally, I made a simple proof of conept/performance demo, which yu can find here: http://afarkas.github.io/responsive-image-race/ In case you find bugs, want to help out or simply want to use it or give some feedback, you are always welcome. (https://github.com/aFarkas/respimage/issues). While working on this "smarter candidate selection", I came to the believe, that also implementers, which even know they are in a highbandwidth enviroment should make some "smarter" candidate selection. For my article, I constructed the following "worst case" example: http://codepen.io/aFarkas/full/tplJE/ and was very sad about how Chrome chooses the best candidate. Really hope such cases will be addressed. Or is it useless hoping? Regards, Alexander Farkas
Received on Monday, 6 October 2014 13:16:43 UTC