[chromium] NOT FOR REVIEW Mark scrollbars as opaque.
Created attachment 125160 [details] Patch
When working on https://bugs.webkit.org/show_bug.cgi?id=77478 , I discovered that we're blending our scroll bars with the debug blue that we're clearing to in LayerRendererChromium.cpp I think that this is clearly an error. The attached patch fixes this. We should also fix it so that Skia gives us an opaque layer (alpha = 1.0). @danakj: How do we fix Skia? Is this a Skia error that I'm seeing? @enne: Is there a better way to mark scrollbars opaque?
Yes. If the background is painted then the scrollbar is painted with alpha over top (those AA corner pixels) skia loses 1 on the alpha channel. Then when its drawn with blending you get the compositor blue coming through. Theres a CL in the works but requires rebaselining the world and I havent worked on it since December. I'll post the bug url later.
Secondly I would like to make chromium paint the scrollbars thru the webkit GraphicsContext instead of directly to canvas. Then opaque paint tracking will know they are opaque automatically.
http://codereview.appspot.com/5494076/
To state the blindingly obvious, scrollbars are often not opaque so this won't work generally.
Just rebaselined the Linux image expectations to bake in the 1 off error in scrollbar alpha.
(In reply to comment #7) > Just rebaselined the Linux image expectations to bake in the 1 off error in scrollbar alpha. I switched us over to mock scrollbars - were you still seeing issues?
(In reply to comment #8) > (In reply to comment #7) > > Just rebaselined the Linux image expectations to bake in the 1 off error in scrollbar alpha. > > I switched us over to mock scrollbars - were you still seeing issues? The baselines that I uploaded for the root clear patch were for the Release build (not root clear). I just ran DRT with a Debug build (still root clears to blue) and there is no error. So you must have fixed it.