Transparent Off Screen rendering: Rendered incorrectly with black background before alpha-channel applied

[GoogleCodeExporter]

What steps will reproduce the problem?
1. set m_bTransparentPainting to true
2. load up a html page with some transparent elements (preferably white)
3. render offscreen output against a bright background (so it gets obvious)

or
use cefclient integrated Off-Screen Rendering test with attached sample HTML 
file

What is the expected output? What do you see instead?
the alpha channel is correct. however not the RGB colors will appear as if 
pre-rendered against a black background before actual alpha channel is applied.
so if you got a white transparent pixel with r255 g255 b255 a127 it outputs as 
r127 g127 b127 a127 in the buffer.
a white transparent box would appear greyish, instead of white

I have attached three files:
test.html - the file i have tested with in cefclient.exe from revision 533 and 
my actual project.
actualoutput.png - the test.html file loaded in the Off-Screen Rendering App 
Example of cefclient.exe resulting in a greyish appearance
comparison.png - the same as "actualoutput.png" but with a transparent white 
Box overlay made with a graphics program for comparison

What version of the product are you using? On what operating system?
I am currently using the Delphi Wrapper of chromiumembedded 
(http://code.google.com/p/delphichromiumembedded/) which currently uses the 
older CEF 1.963.439. However i made tests with the cefclient from the current 
revision 533.

Original issue reported on code.google.com by normanhe...@fotona.de on 27 Apr 2012 at 12:16

Attachments:

• test.html
• actualoutput.png
• comparison.png

[GoogleCodeExporter]

Original comment by magreenb...@gmail.com on 18 May 2012 at 10:22

• Changed state: Accepted

[GoogleCodeExporter]

Revision 643 improves the cefclient transparency test by adding the ability to 
view individual pixel values.

Original comment by magreenb...@gmail.com on 23 May 2012 at 5:40

[GoogleCodeExporter]

Transparent painting in WebKit works as follows:

1. GraphisContext::beginTransparencyLayer creates a new layer (bitmap) for the 
transparent region.

2. Painting is done on the new layer using just RGB values.

3. GraphicsContext::endTransparencyLayer is called to paint the new layer onto 
the underlying layer and apply the alpha component at the same time.

The call stack for #3 is as follows:

>   libcef.dll!S32A_Blend_BlitRow32_SSE2(unsigned int * dst, const unsigned int * 
src, int count, unsigned int alpha)  Line 233   C++
    libcef.dll!Sprite_D32_S32::blitRect(int x, int y, int width, int height)  Line 48 + 0x15 bytes  C++
    libcef.dll!blitrect(SkBlitter * blitter, const SkIRect & r)  Line 15 + 0x2e bytes   C++
    libcef.dll!SkScan::FillIRect(const SkIRect & r, const SkRegion * clip, SkBlitter * blitter)  Line 26 + 0xd bytes    C++
    libcef.dll!SkScan::FillIRect(const SkIRect & r, const SkRasterClip & clip, SkBlitter * blitter)  Line 77 + 0x16 bytes   C++
    libcef.dll!SkDraw::drawSprite(const SkBitmap & bitmap, int x, int y, const SkPaint & origPaint)  Line 1248 + 0x17 bytes C++
    libcef.dll!SkDevice::drawDevice(const SkDraw & draw, SkDevice * device, int x, int y, const SkPaint & paint)  Line 357  C++
    libcef.dll!SkCanvas::drawDevice(SkDevice * device, int x, int y, const SkPaint * paint)  Line 858 + 0x4e bytes  C++
    libcef.dll!SkCanvas::internalRestore()  Line 799    C++
    libcef.dll!SkCanvas::restore()  Line 769    C++
    libcef.dll!WebCore::GraphicsContext::endPlatformTransparencyLayer()  Line 290 + 0x21 bytes  C++
    libcef.dll!WebCore::GraphicsContext::endTransparencyLayer()  Line 346   C++

So, in conclusion, the S32A_Blend_BlitRow32_SSE2 function intentionally applies 
alpha blending to all 4 components of the RGBA value.

Original comment by magreenb...@gmail.com on 24 May 2012 at 6:16

[GoogleCodeExporter]

For example, in S32A_Blend_BlitRow32_SSE2:

alpha     = 0xbf
src_pixel = 0xffffffffffffffffffffffffffffffff (new/transparent layer)
dst_pixel = 0000000000000000000000000000000000 (underlying layer)
result    = 0xbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbf

Original comment by magreenb...@gmail.com on 24 May 2012 at 6:44

[GoogleCodeExporter]

Related skia issue: http://code.google.com/p/skia/issues/detail?id=547

Original comment by magreenb...@gmail.com on 24 May 2012 at 8:58

[GoogleCodeExporter]

Started a thread about this on the skia-discuss mailing list: 
http://groups.google.com/group/skia-discuss/browse_thread/thread/b15e9eddda5fe02
1

Original comment by magreenb...@gmail.com on 24 May 2012 at 9:23

[GoogleCodeExporter]

good you found a lead. i suspected that it is nothing that comes from cef 
itself. thanks for your dedication in this project :)

Original comment by normanhe...@fotona.de on 24 May 2012 at 10:50

[GoogleCodeExporter]

Skia writes premultpilied alpha. That's the only pixel format you're going to 
get out of Chromium.

Original comment by tomhudson@google.com on 25 May 2012 at 12:19

[GoogleCodeExporter]

Revision 648 updates the cefclient example to account for premultiplied alpha 
values.

Original comment by magreenb...@gmail.com on 25 May 2012 at 2:24

• Changed state: Fixed

[GoogleCodeExporter]

Ahh, I was wondering if it was a question of blend functions. Nice clean fix.

Original comment by tomhudson@google.com on 25 May 2012 at 2:25

[GoogleCodeExporter]

The cefclient changes have been merged to all branches in revision 649.

Original comment by magreenb...@gmail.com on 25 May 2012 at 2:35