[Webkit-unassigned] [Bug 51928] [chromium] Enable reuse of RenderSurface for drawing.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=51928





--- Comment #12 from Vangelis Kokkevis <vangelis at chromium.org>  2011-01-07 10:11:54 PST ---
(In reply to comment #10)
> (In reply to comment #8)
> > This change seems to violate the comment above it:
> > 
> >     // Mask out writes to alpha channel: subpixel antialiasing via Skia results in invalid
> >     // zero alpha values on text glyphs. The root layer is always opaque.
> >     m_context->colorMask(true, true, true, false);
> > 
> > Either this change is wrong, or the comment is wrong.  Vangelis, what do you think?
> 
> I've moved the comment along with the change to the color mask, but I do not know about the origin of the comment.
> 
> I'm happy to prepare a test-patch people could apply to ToT to see for themselves the difference between leaving the alpha mask on and off, if that would help. As mentioned earlier, so far it's just the one test case I know of that triggers it.

Here's my suspicion as to what's happening:  The RenderSurface's texture starts out with Alpha = 1 for all pixels (which is guaranteed from setting the colorMask to (true, true, true, true) and clearing).  The code subsequently masks out alpha writes which should guarantee that the RenderSurface texture keeps alpha = 1 for all pixels all the way through.

In the offscreen rendering path, if your window backbuffer was never cleared, it could have non-one alpha values for pixels so when you render the one large quad with the RenderSurface's contents, since you are masking alpha, you won't affect the existing alpha values.  

Can you try setting the color mask back to (true, true, true, true) before drawing the offscreen texture into the final window backbuffer?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.