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

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.

> 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.

/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.