2012/8/13 Ilyes Gouta <ilyes.go...@gmail.com>
> 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.
>
Maintaining N rows is an implementation detail of the scaler. I mean by
having a simple one-scanline-in, zero-or-more-scanlines-out interface, like
this:
scaler.setSourceSize(10, 10);
scaler.setDestSize(100, 100);
while (decoder.hasMoreScanines()) {
scaler.supplyScanLine(decoder.nextScanine());
while (scaler.hasMoreScanlines())
memcpy(dest.nextOutputScanline(), scaler.nextScanline(), width * 4);
}
Then what algorithm to use and quality is up to the scaler implementation
to decide.
Alpha
>
> -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
