W3C home > Mailing lists > Public > www-style@w3.org > April 2007

Re: CSS Opacity

From: Daniel Beardsmore <public@telcontar.net>
Date: Sun, 29 Apr 2007 05:08:51 +0100
Message-ID: <46341A53.4060602@telcontar.net>
To: www-style@w3.org

David Hyatt wrote:
> Sure, but using opacity is much worse, since you'll force the Web  
> engine to make an offscreen buffer to render the image into before  
> then blending it with the destination.  One transparent image buffer  
> from a PNG is going to be way more efficient than having a non- 
> transparent image buffer + an entire offscreen buffer just to do the  
> blend.

I am not sure there is any reason why this has to be the case. When plotting 
pixels that are governed by opacity, you cannot simply multiply them by the 
opacity as you go?

I also don't know how JPEG+opacity is any heavier a load than a PNG with alpha. 
PNG images sit in memory as raw PNG to be handled by the OS? Is this something 
that every "OS" (read, OS/window manager/widget set) features, or is direct PNG 
support only a feature of Core Image that Apple is relying on in Mac OS X only?

You are hinting that Core Image has a fancy direct PNG blitter that doesn't 
require unpacking the PNG image first as a linear image before rendering it? 
Otherwise, unpacking the PNG into a linear image would be no different to 
unpacking a JPEG into a linear image and then slapping a fixed alpha channel on it.

You need to be a bit more specific about what Safari gets up to and whether it 
also applies the same way to Qt/GTK+/GDI/GDI+/etc.

It sounds like what we need, after all, is that JPEG+alpha blitter ...
Received on Sunday, 29 April 2007 04:10:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:50 GMT