Jack, I worked with Niels offline to understand the issue. Niels found the issue and fixed it. He provided a patch for 1.3.x which I backported to 1.0.1 (which was relatively painless). Niels recently indicated that he was planning on adding the fix to 1.3.x. I'll let Niels send you the patch of the work he did (quite promptly I might add) if you'd like a copy.
Thanks Niels! Seeing as he did the fix, I'll let him speak to what he did to fix the issue. Bryce Intel Corporation -----Original Message----- From: directfb-dev-boun...@directfb.org [mailto:directfb-dev-boun...@directfb.org] On Behalf Of MrPeach Sent: Thursday, February 19, 2009 11:23 AM To: directfb-dev@directfb.org Subject: Re: [directfb-dev] Software blending abnormalities in DirectFB 1.0.1 Bryce, I recalled your question and as I happened to be digging through generic.c this week (implementing my own accelerator code) I thought I'd give you a reply. Looking at the code in generic.c, I see the following: if (source_needs_destination && state->dst_blend != DSBF_ONE) { *funcs++ = Xacc_is_Bacc; *funcs++ = Xacc_blend[state->src_blend - 1]; *funcs++ = Xacc_is_Aacc; *funcs++ = Xacc_blend[state->dst_blend - 1]; } It applies the source blend first, then the results of that are used in the second blend. I don't know if this is the "correct" behavior, but it doesn't seem to me that it is. However, the only way to make it behave "correctly" would be to make a copy of the first used accumulator array and use that in the second operation, which would be costly. Jack Follansbee Broadcom Corporation On Mon, 5 Jan 2009 12:31:22 -0800, "Poole, Bryce" <bryce.po...@intel.com> wrote: >All, >I have been doing some validation of the hardware driver that we have >developed based on OpenGL ES and came up with some peculiar results when >comparing it to software blending. When blitting ARGB surfaces, the software >blending seems to be different for several of the src/dest blend function >combinations when compared to OpenGL. Is there anyone here that worked on the >software blender? I am trying to confirm that the results I see are expected. > >In an attempt to establish the expected behavior, I hand blended the colors to >verify the results and concluded that the hand calculated/blended colors most >closely matched the OpenGL blender. Not all combinations of blending >functions produced different results. These are some of the combinations that >didn't produce the expected results: >Src: DstAlpha Dst: SrcColor >Src: DstAlpha Dst: 1-SrcColor >Src: DstAlpha Dst: SrcAlpha >Src: DstAlpha Dst: 1-SrcAlpha > >Src: 1-DstAlpha Dst: SrcColor >Src: 1-DstAlpha Dst: 1-SrcColor >Src: 1-DstAlpha Dst: SrcAlpha >Src: 1-DstAlpha Dst: 1-SrcAlpha > >Src: DstColor Dst: SrcColor >Src: DstColor Dst: 1-SrcColor >Src: DstColor Dst: SrcAlpha >Src: DstColor Dst: 1-SrcAlpha > >Src: 1- DstColor Dst: SrcColor >Src: 1- DstColor Dst: 1-SrcColor >Src: 1- DstColor Dst: SrcAlpha >Src: 1- DstColor Dst: 1-SrcAlpha > >Src: SrcAlphaSat Dst:SrcColor >Src: SrcAlphaSat Dst:1-SrcColor > >This doesn't include all possible combinations, only those valid in OpenGL ES. > >For an example, the following demonstrates the results that I see. > >The Blend equation is Color(final) = Color(src)*BlendFunction(src) + >Color(dst)*BlendFunction(dst). >BlendFunction(src) = DstAlpha >BlendFunction(dst) = SrcColor > >R(final) = R(src)*A(dst)/255 + R(dst)*R(src)/255 >G(final) = G(src)*A(dst)/255 + G(dst)*G(src)/255 >B(final) = B(src)*A(dst)/255 + B(dst)*B(src)/255 >A(final) = A(src)*A(dst)/255 + A(dst)*A(src)/255 > >Src Color: 0x6e728cff >ARGB=110 114 140 255 >Dst Color: 0x7c8cdb72 >ARGB=124 140 219 114 > >R(final) = 114*124/255 + 140*114/255 = 55 + 63 = 118 >G(final) = 140*124/255 + 219*140/255 = 68 + 120 = 188 >B(final) = 255*124/255 + 114*255/255 = 124 + 114 = 238 >A(final) = 110*124/255 + 124*110/255 = 53 + 53 = 106 > >To compare (ARGB): >079 085 127 179 Software >107 118 188 234 Hardware >106 118 188 238 Hand Calculation > >As can be seen in the calculations above, the software blender produces >substantially different values compared to the expected result. The hardware >and hand calculations are close. > >Can anyone help me to understand what is going on? This is for DirectFB >1.0.1. If someone wants to run this on DirectFB 1.4, that would be >appreciated. > >Bryce Poole >Intel Corporation > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
