W3C home > Mailing lists > Public > public-respimg@w3.org > September 2013

Re: Compressive images test

From: Jason Grigsby <jason@cloudfour.com>
Date: Fri, 13 Sep 2013 10:53:53 -0700
Message-ID: <CADQU=pOq37WsM4J3apF9NrfcB3d_DieyXT9DtNbJD2Ex+cfM7A@mail.gmail.com>
To: Anselm Hannemann <info@anselm-hannemann.com>
Cc: Ben Callahan <ben@heysparkbox.com>, "public-respimg@w3.org" <public-respimg@w3.org>
On Fri, Sep 13, 2013 at 9:46 AM, Anselm Hannemann <info@anselm-hannemann.com
> wrote:

>
> I would really be interested in some statistics that clarify when they
> work and where not.
> Problem is to measure the impact. AFAIK only Chrome provides such DevTool
> measurement tools, right? Or do you have something in your mind how this
> can be measured automatically?
>
>
>From my conversations with the Chrome team, I don't think we could easily
measure it in Chrome either. Here is what one of the engineers sent me
earlier this year when I was asking about how to construct a test to
measure the memory impact of compressive images:

It wouldn't surprise me if the profiler doesn't show it. Your best bet
> might be to load both images in new incognito windows and compare the
> amount of memory shown in Chrome's task manager. If that doesn't work,
> we'll probably need to instrument it by hand.
>


Images are stored in memory in 3 (!) places in Blink/WebKit:
>


1. The unmodified downloaded bytes are stored in the memory cache.
> 2. The full size decoded bitmap is also stored in the memory cache.
> 3. The scaled down bitmap seen onscreen is stored in the tile cache.
>


The technique described on that page basically saves memory in #1 by using
> more memory in #2.
> If we're under memory pressure, we'll of course evict things from these
> caches. IIRC, the decoded image cache (#2) is the first to evict. I could
> imagine that leading to more thrashing, but the smaller image file is
> likely going to be faster to decode too.


This led me to believe that instrumenting it was probably not going to work
because if we couldn't get good data from Chrome, the chances of getting it
from a feature phone is non-existent.

I think we're looking at crude tests like what Ben suggested. Progressively
more challenging pages that we then have a bunch of people test on a range
of devices and ask people to observe behavior. Does it crash the browser?
Is scrolling slower? Etc.

I can't think of a way to make it scientific, but perhaps we can do
something that is at least informative.

-Jason
Received on Friday, 13 September 2013 17:54:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:40 UTC