Re: Drawing to different bitmap formats

On Tue, Aug 14, 2012 at 5:42 AM, Bob Holmes <rangsynth@gmail.com> wrote:

> The spec is dealing only with drawing to bitmaps with premultiplied
> alpha channel.


This spec doesn't talk about bitmaps.
It describes how shapes and groups of shapes interact. A 'shape' can be
anything (text, graphics, bitmaps, gradient, ...)


> 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.
>

I can't think of any specs on w3c that describe how you should implement
them.
A spec's target audience is both web authors and implementers and it should
be readable to both. In addition to the spec, there is also a set of test
files that an implementer can use to validate that he/she coded the right
solution.

It seems that you deduced from the spec wording how the bitmaps should be
handled and then figured out that you can optimize this process under
certain circumstances.
If we start adding implementation notes, we'd have to do it for all
technologies (ie different GPU implementations). It would also not be
future proof.

Rik