[webkit-dev] WebKit runtime image compression

Paul Pedriana ppedriana at gmail.com
Mon Dec 15 13:43:08 PST 2008

Thanks. I didn't mean to suggest something like this should be part of 
WebKit. I was wondering if anybody had any experience they could share 
that might help me or others come to faster conclusions about the 
usefulness or feasibility of this in custom ports. If I implement the 
formats below I can report back on my results and possibly donate to 
ports that might be interested in this, such as OWB.



> On Dec 14, 2008, at 1:12 AM, Paul Pedriana wrote:
>> For a lot of web pages, images are the primary source of memory 
>> usage. These images seem to be typically stored as RGB or ARGB data 
>> in the BitmapImage class.
> This isn't always true though.  For example, the ports that use CG 
> have CGImageRefs and not raw ARGB data.
>> It seems to me that applications that wish or need to save runtime 
>> memory could benefit from runtime image compression whereby images 
>> are stored in some compressed form instead of RGB or ARGB formats. I 
>> am currently looking into this possibility and I'm wondering if 
>> anybody has previously looked into it.
>> My current idea is to support two kinds of compressed images: RLE and 
>> YCoCg-DXT5. The former could be for any images that are simple 
>> enough, and the latter could be for general images and give a fixed 
>> 4:1 compression ratio. RGB transforms to YCoCg with better 
>> decorrelation (breakdown of RGB to YCC) than YCbCr and many images 
>> can get PSNR values over 40 (i.e. hard to tell from original). If the 
>> computer has decent vector processing or a programmable GPU, the 
>> performance could be decent, otherwise it depends on the CPU. (A)RGB 
>> could of course remain as a fallback.
>> I'm wondering if anybody has looked into runtime image compression 
>> with WebKit and considered options such as this.
> This could in theory be done as a separate library that is then just 
> used by the specific ports of WebKit that might need it.  I'm not 
> convinced it would need to be part of WebKit itself.
> dave

More information about the webkit-dev mailing list