- From: Bob Holmes <rangsynth@gmail.com>
- Date: Tue, 14 Aug 2012 14:42:03 +0200
- To: "www-svg@w3.org" <www-svg@w3.org>
The spec is dealing only with drawing to bitmaps with premultiplied alpha channel. But as I am making my forms engine I see that the best optimization is for most forms to just draw to a bitmap with no alpha channel at all, because then when it is done it can just be sent directly to the screen on both Mac and on Windows, so for forms that require alpha channel the format of the underlying bitmap can just be changed. I think it will help if there was a section on drawing to different bitmap formats and specifically how that works just after the composite operator. For drawing to 24 bit bitmap you take the output of the composite operator and "matte with white", like so...(co is premultipled output of composite op) BGR24[r] = co.r + (255 - co.a) BGR24[g] = co.g + (255 - co.a) BGR24[b] = co.b + (255 - co.a) And for 32 bit bitmap BGRX like so... BGRX32[r] = co.r + (255 - co.a) BGRX32[g] = co.g + (255 - co.a) BGRX32[b] = co.b + (255 - co.a) BGRX32[a] = 255(A in BGRX is not actually used) And then to draw to bitmaps with alpha channel but the format is not premultiplied, like BGRA(vs. PBGRA) BGRA32[r] = Unpremul(co.r,co.a) BGRA32[g] = Unpremul(co.g,co.a) BGRA32[b] = Unpremul(co.b,co.a) BGRA32[a] = 255 And for bitmap format like SVG spec is using, or PBGRA, premultiplied BGRA, is like so... BGRA32[r] = co.r BGRA32[g] = co.g BGRA32[b] = co.b BGRA32[a] = co.a Which on Little endian system like MS Windows or Mac 386 is just BGRA32 = co since the bytes are laid out the same... -------- I think this is important for implementors to understand so that drawing engines can be optimized for cases where the alpha channel is not important in some intermediate drawing. For example, I want a bitmap with some white background, and then some color shapes or text on the white background, but the alpha is not needed to be saved, I can then draw directly to a simpler bitmap format and save time without having to unpremultiply anything in stages that do not use that concept. The same composite/blending code can be used for both the normal PBGRA cases as for other formats, and all that changes is how the result of the compositor is stored in the underlying bits. For people like me from a forms background drawing onto 24 bit bitmaps the concept of PBGRA only can be strange, which is why I suggest this. Thanks.
Received on Tuesday, 14 August 2012 12:42:47 UTC