Hi, >>> If such a callback API for row-based resizing comes to fruition, then >>> let's (also) not rule out whole-picture h/w accelerated resizing - >>> such as by making that new API a mandatory stage in the decoding
that's actually: such as by *not* making that new API a mandatory stage in the decoding >>> process. > I agree we should have a separate row-based downscaling phase. Resizing and filtering on a single row isn't enough. For a good quality and depending on the scaling ratio, we should maintain N rows, with N depends on the maximum downscaling or upscaling factor. -Ilyes > nice to have a callback based downscaling API that we can implement better > algorithms. On Mon, Aug 13, 2012 at 6:52 PM, Alpha Lam <hc...@chromium.org> wrote: > I agree we should have a separate row-based downscaling phase. > > JPEGImageDecoder.cpp already supports downscaling with a given width and > height, but it's using point sampling which has poor quality. It would be > nice to have a callback based downscaling API that we can implement better > algorithms. > > Alpha > > 2012/8/13 Alpha (Hin-Chung) Lam <hc...@google.com> > >> I agree we should have a separate row-based downscaling phase. >> >> JPEGImageDecoder.cpp already supports downscaling with a given width and >> height, but it's using point sampling which has poor quality. It would be >> nice to have a callback based downscaling API that we can implement better >> algorithms. >> >> Alpha >> >> >> 2012/8/13 Ilyes Gouta <ilyes.go...@gmail.com> >>> >>> Hi, >>> >>> On Mon, Aug 13, 2012 at 3:46 PM, Anton Obzhirov <a.obzhi...@samsung.com> >>> wrote: >>> > Libjpeg has some internal support for downscaling already (2x, 4x). Not >>> > sure >>> > about >>> > >>> > Libpng and other libraries. In general probably it can be implemented >>> > by >>> > downscaling decoded row of the pixels on the fly using callback API >>> > provided. >>> >>> If such a callback API for row-based resizing comes to fruition, then >>> let's (also) not rule out whole-picture h/w accelerated resizing - >>> such as by making that new API a mandatory stage in the decoding >>> process. >>> >>> -Ilyes >>> >>> > >>> > From: tomhud...@google.com [mailto:tomhud...@google.com] On Behalf Of >>> > Tom >>> > Hudson >>> > Sent: 13 August 2012 15:00 >>> > To: webkit-dev@lists.webkit.org; Anton Obzhirov >>> > Subject: Fwd: [webkit-dev] image downscaling during decoding >>> > >>> > >>> > >>> > On Mon, Aug 13, 2012 at 9:39 AM, Anton Obzhirov >>> > <a.obzhi...@samsung.com> >>> > wrote: >>> > >>> > >>> > >>> > We are looking for ways to improve page loading speed and reduce memory >>> > usage for WebKit in general and for GTK port of WebKit in particular. >>> > >>> > One of the ideas is to implement downscaling of the images during >>> > decoding >>> > for image elements with rectangle less then original image size. >>> > >>> > At the moment such images are full decoded to a full size buffer and >>> > get >>> > downscaled during rendering. >>> > >>> > It can be quite beneficial in term of memory usage and should speed up >>> > rendering of the pages like image galleries for example. >>> > >>> > So what are your thoughts about it? >>> > >>> > >>> > >>> > Interesting idea! I know Chrome sees memory pressure from the >>> > downsampling >>> > two-step on some pages, so I'd think this is could be useful for us, >>> > too. >>> > >>> > >>> > >>> > Isn't it going to require fairly large and intrusive changes to several >>> > different third-party libraries, though? >>> > >>> > Also, different ports use different image downscaling algorithms; I can >>> > think of ways to try to enable incremental downscaling callbacks so you >>> > don't have to implement N downscales in each of M decoders, but none >>> > that >>> > are both general and performant. >>> > >>> > >>> > >>> > I'd love to see a proposal on this. >>> > >>> > >>> > >>> > Tom >>> > >>> > (from the right account this time) >>> > >>> > >>> > _______________________________________________ >>> > webkit-dev mailing list >>> > webkit-dev@lists.webkit.org >>> > http://lists.webkit.org/mailman/listinfo/webkit-dev >>> > >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo/webkit-dev >> >> > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
