From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <14ec7b180903041807q58ae6a8fh31350709edd0c0c@mail.gmail.com> <14ec7b180903051921u10524f16naad654b297a67de3@mail.gmail.com> Date: Fri, 6 Mar 2009 14:42:41 -0700 Message-ID: <14ec7b180903061342r1adca970gc1efa508ff9c8fb8@mail.gmail.com> From: andrey mirtchovski To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Porter-Duff alpha blending Topicbox-Message-UUID: b50afe64-ead4-11e9-9d60-3106f5b1d025 > Bug #3: MUL0123 is enabled whenever the src > and dst both have 32-bit pixel width, but there is > no check that the sub-channels are in the same > order. You don't say what the image chans were > in your test, but this: > > src rFF g00 b00 =CE=B1FF > mask kFF =CE=B1FF > dst r00 g00 b00 =CE=B1FF > dst after calc rFE gFE b00 =CE=B100 > > would be explained by, say, src=3D=3DARGB and > dst=3D=3DRGBA. The A and R values in src became > the R and G chans in dst. (In fact, since the dst > R and G are FE not FF, that's almost certainly > the scenario, modulo the little-endian draw names.) it was indeed ARGB/RGBA (or the other way around) as I had focused testing only on those two. thanks for the explanation!