Re: [public-respimg] Best Practice Resizing + Asset Re-Downloading / Resp ImageFormat

On 05.07.2013, at 10:26, Tom Maslen <tom.maslen@bbc.co.uk> wrote:
> Hi,
> 
> > Always keep in mind that people might be on costly network connection and might not want to
> re-download another image that only slightly improves quality.
> 
> Yep totally agree, not many people resize their screens constantly (apart from developers playing with responsive sites) so we're not causing the internet to melt.  This would have a negative effect on our servers too (we have big web traffic scaling issues).
> 
> We also use JS for the initial image load, so 99% of the time the user hopefully only gets 1 image.
> 
> 
This is great, thanks for clarifying. :)
> > Speaking of resizing performance impacts you there won't be any on such slight resizes. What I was speaking about
> are resized images like 2048px*1536px down to 1024*768px or even larger (panoramic images). There you can clearly
> see the CPU/GPU of the devices is too slow to repaint that in time on cheap mobile phones.
> 
> Do you have any other examples?  This is the first time I've read anyone mention specific pixel values in relation to scaling issues.
> 
Unfortunately not. I may dig into this as this topic seems to be quite interesting but not sure when I find time to test this 
in the device lab properly.

-A.
> 
> /t
> 
> 
> Tom Maslen
> Tech Lead
> BBC News Visual Journalism
> 
> 
> 
> -----Original Message-----
> From: Anselm Hannemann [mailto:info@anselm-hannemann.com]
> Sent: Fri 7/5/2013 9:14 AM
> To: Tom Maslen
> Cc: Marcos Caceres; Ritchie Anesco; Mohsen Nabiloo Azimi; public-respimg@w3.org
> Subject: Re: [public-respimg] Best Practice Resizing + Asset Re-Downloading / Resp ImageFormat
> 
> On 05.07.2013, at 09:47, Tom Maslen <tom.maslen@bbc.co.uk> wrote:
> > Is there a hard limit to how much you can get away with scaling the image up/down before its better to just download an alternative image?
> >
> > When I made the responsive images solution for m.bbc.co.uk/news we didn't have any data to make a decision about this so I just guessed and made the images scale 100% to fit its containing element, but then get the JS to swap the image out for a better fitted alternative every 30px.
> >
> > /t
> >
> > Tom Maslen
> > Tech Lead
> > BBC News Visual Journalism
> >
> Tom,
> 
> --- First, I changed the subject to a more useful one as <none> doesn't help anyone searching the archives. ---
> 
> You're definitely hitting a good point here. I didn't ever researched this in detail unfortunately.
> But if you are using a JavaScript which dynamically requests different sizes of images
> depending on the screen size you should be careful loading new assets.
> 
> Always keep in mind that people might be on costly network connection and might not want to
> re-download another image that only slightly improves quality.
> This is not only on mobile devices but targets users tethering their connection to their notebook or similar.
> 
> Therefore I would only re-download an asset if it dramatically changes its content (art-direction use case)
> or quality (say from 320px to ~800px). Every 30px seems to be too much.
> If you only do this once onload and not dynamically onresize your approach is indeed very good
> although 30px is already very granular and means you have to keep a lot of different
> sizes of your assets on your servers.
> 
> Speaking of resizing performance impacts you there won't be any on such slight resizes. What I was speaking about
> are resized images like 2048px*1536px down to 1024*768px or even larger (panoramic images). There you can clearly
> see the CPU/GPU of the devices is too slow to repaint that in time on cheap mobile phones.
> 
> Cheers,
> Anselm  |  @helloanselm  |  helloanselm.com
> 
>  
> 
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.