[Webkit-unassigned] [Bug 52311] [chromium] Add command-line flag to enable composite to offscreen texture.

[bugzilla-daemon at webkit.org]

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





--- Comment #36 from Vangelis Kokkevis <vangelis at chromium.org>  2011-01-18 16:15:32 PST ---
(In reply to comment #34)
> (In reply to comment #33)
> > Created an attachment (id=79326)
 --> (https://bugs.webkit.org/attachment.cgi?id=79326&action=review) [details] [details]
> > Patch
> 
> OK, this patch is an attempt to recover after the confusion of the last patch, where I suspect I was quite testing what I thought I was testing ...
> 
> Comments:
> 
> 1) I have added a function called clearFramebuffer() to LayerRendererChromium and called it from initializeSharedObjects() to clear the display. Without this, a large number of tests fail on a Skia assertion
> 
> SkASSERT(r < a)
> 

I think there's a good opportunity now that you're getting the assert to understand what's going wrong here.  Clearing the framebuffer at init time seems to mostly work but I'm curious why (and why it causes that one failure) and whether it's masking some other problem.  

Have you tried calling:

m_context->colorMask(true, true, true, true)

in copyOffscreenTextureToDisplay() before drawing ?  The texture attached to the m_defaultRenderSurface should have a clear alpha channel.



> suggesting the alpha channel is unhappy. Placing it in initializeSharedObjects() means it gets cleared only once.
> 
> Question: is there any reason we should also do clearFramebuffer(m_offscreenFramebufferId)?
> 
> 2) I have proposed a fix for setScissorRect() for the use case useRenderSurface(0) ... let me know if using thew contentRect from m_defaultRenderSurface seems correct. It seems to display OK for all cases I've tried.
> 
> 3) Similarly, I've had to test for renderSurface == 0 in useRenderSurface and default to setting the drawViewPortRect according to m_defaultRenderSurface when renderSurface is 0.
> 
> 4) A small number of test cases seem to have slight changes in pixel intensities --- imperceptible to my eye --- that seem to again be related to alpha channel values. One in particular, compositing/iframes/composited-iframe-alignment.html, tests fine if I delete the line clearFramebuffer(0) from initializeSharedObjects(), but this of course messes up a bunch of other tests (see (1)).
> 
> I would like to proceed with the patch despite these tests (can we temporarily mark them as expected-fail for offscreen compositing, or rebaseline for the offscreen case?). I will continue to try and hunt down the cause, but I think this will be easier once offscreen-compositing is part of the test suite (to prevent any other regressions).

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