- From: 暴雨不在明天 <bybzmt@gmail.com>
- Date: Thu, 16 Feb 2012 14:25:51 +0800
- To: Hawkeyes Wind <hawkeyes0.cn@gmail.com>
- Cc: public-html-ig-zh@w3.org
- Message-ID: <CABNxgEng_7eZbeFQmk3B+YkjCB2Ca5tAtmd5dnpTEXsxJu0U6w@mail.gmail.com>
好像我们说的不是一个东西。。。我的意思是定义一种新的图片传输封装方式,恩有点类似于视频里的流媒体那种,用户快进到哪一段就从服务器上加载哪一段,并且可以缓存。 以现在的情况来说的话可能实现成一个loader的接口会比较合适(可以平滑过度) <img loader="xxxx"... 由loader解决加载和渲染实现 在 2012年2月16日 下午2:13,Hawkeyes Wind <hawkeyes0.cn@gmail.com>写道: > 首先,并不是所有jpg格式的图片都能隔行加载,其次浏览器应该做的是根据网页作者定义的width、height、max-width、 > max-height、min-width、min-height的样式来显示图片的大小,就算是个大图也能用样式缩得很小。 > > 根据jpeg的算法,从一张缩略图和原图之间的二进制比较结果来看,并没有相同的数据存在。 > > 另一方面来说,如果由浏览器根据图片大小强制终止文件传输,可能的结果是服务器的内存在一定时间内无法被释放,从而增加服务器端压力。 > > 缩略图的意义在于减少传输量,但这并不是浏览器的职责。 > > 于 2012/2/16 13:24, 暴雨不在明天 写道: > > 我说的是部分加载功能,类似于jpg的隔行加载功能。 > 如果缩略图只有原图1/4大那只要4像素取1像素就可以了,这样就只传输了1/4的数据(这部分由服务器完成) > > 在 2012年2月16日 下午1:00,Hawkeyes Wind <hawkeyes0.cn@gmail.com>写 道: > >> 如果由浏览器来处理缩略图 的话,用户依旧需要下载完整的大尺寸图片。这种情况 下用户需要等待的时间会大大增加。 >> >> >> 所以还是由服务器端处理缩略图是比较合理的。服务器可以只存大图,再根据页面 的不同临时生成缩略图传递给用户会比较好。 >> >> 于 2012/2/16 11:51, -暴雨不在明天 写道: >> >> 缩略图是现在web上非常非常常用的一个功能。 >>> >>> 应用场景: >>> 1. 当页面需要显示很多图片时,通常我们只显示这些图片的 >>> 缩略图从而加快页面的显示。而大图通常需要点击后才能显示。 >>> >>> 2. 相册的应用中,一般会会先显示缩略图然后用户点击查看 >>> 感兴趣的图片,当用户对某些图片特别感兴趣可能还原查看或 >>> 下载原始尺寸的图片(通常会非常大)。 >>> >>> 但是这种应用并不完美: >>> 1. 我们需要在服务器端为同一张图片保存不同尺寸的缩图,这 >>> 很些图片的创建/管理是一件很麻烦的事情。另外对服务器空间也 >>> 影响(虽然对现在硬盘来说影响相对小)。 >>> >>> 2. 在客户端我们需要为同一张图片的不同尺寸的图片建立不同的 >>> 链接,而且当我们需要查看更大尺寸的图片时,前面载入的缩略图 >>> 数据并不能起到作用,这会浪费相当的流量。而且我们在相册的应用 >>> 中,大图和原图可能相差不多大或者根本就是一样的,这个时候的浪 >>> 费是相当大的。 >>> >>> 如果我们能在浏览器上建立对缩略图的支持我就可以避免这种情况。 >>> 例如: >>> 我们有一张1920*1200的图片. >>> html:<img src="img_01" style="width:480px;height:300px" /> >>> 这里浏览器可以: >>> request: img_01 >>> size:480,300 >>> 服务器可以直接从图片中取出相应的数据反回过来 >>> (4个像素中取1个像素就可以) >>> 这个时候如果用户需要查看大图就会: >>> request:img_01 >>> cache:480,300 >>> size:1280,800 >>> 服务器可以去掉己缓冲的480,300部分而反数据 >>> >>> 这样我们的缩略图就是可以大大简化了(对程序员来说) >>> 而且可以实现无级缩放,并有效降低网络负载。 >>> 还可以让用户在web上对图片进行放大缩小操作,就像我们查看 >>> 本地图片一样,这时用户体验会有很大提升。 >>> >>> ps:话说这只是我早上起床灵光一闪并没有仔细考虑,大家不要见笑。 >>> >> >> -- >> Regards >> >> Hawkeyes Wind >> >> >> > > -- > Regards > > Hawkeyes Wind > >
Received on Thursday, 16 February 2012 06:30:55 UTC