Move as much as possible of the edge intersection and vertex offset code used for layer anti-aliasing to the vertex shader.
I've looked at this and it's not obvious to me how this can be done well. We could just move the edge intersection code to the vertex shader but I'm not sure what that buys us. We end up needing 12 uniforms instead of the current 8. We could pass the edges to the fragment shader as varying variables this way but I'm not sure that's an improvement. I also looked at moving all edge related code to the vertex shader but I haven't found a way to perform perspective correct transformations without passing the layer-to-device matrix/inverse to the shader in addition to the current projection*draw-transform. any suggestions?
Created attachment 106067 [details] Move edge intersection code used for anti-aliasing to shader. Doesn't currently apply. Depends on https://bugs.webkit.org/show_bug.cgi?id=66437. I'll upload a proper patch for review once 66437 has landed.
Created attachment 106628 [details] Patch
Created attachment 106886 [details] Patch
(In reply to comment #1) > I've looked at this and it's not obvious to me how this can be done well. > > We could just move the edge intersection code to the vertex shader but I'm not sure what that buys us. We end up needing 12 uniforms instead of the current 8. We could pass the edges to the fragment shader as varying variables this way but I'm not sure that's an improvement. > > I also looked at moving all edge related code to the vertex shader but I haven't found a way to perform perspective correct transformations without passing the layer-to-device matrix/inverse to the shader in addition to the current projection*draw-transform. Yeah, I think my naive hope before looking into the details was that (1) maybe the vertex shader would be an appropriate place to do all these vertex manipulations and (2) it would be a good abstraction for all of the edge calculations that are now needed when drawing surfaces and tiles. I agree with you that I'm not sure what the partial solution buys us. It's not really a win for either (1) or (2).
Created attachment 107191 [details] Patch
(In reply to comment #5) > (In reply to comment #1) > > I've looked at this and it's not obvious to me how this can be done well. > > > > We could just move the edge intersection code to the vertex shader but I'm not sure what that buys us. We end up needing 12 uniforms instead of the current 8. We could pass the edges to the fragment shader as varying variables this way but I'm not sure that's an improvement. > > > > I also looked at moving all edge related code to the vertex shader but I haven't found a way to perform perspective correct transformations without passing the layer-to-device matrix/inverse to the shader in addition to the current projection*draw-transform. > > Yeah, I think my naive hope before looking into the details was that (1) maybe the vertex shader would be an appropriate place to do all these vertex manipulations and (2) it would be a good abstraction for all of the edge calculations that are now needed when drawing surfaces and tiles. > > I agree with you that I'm not sure what the partial solution buys us. It's not really a win for either (1) or (2). Yes, no not a huge win. We get some of (2) by moving the edge intersection into the shader. Tiled layers are always going to need some special treatment but the render surface code which is what would be used with other non-tiled layers is pretty minimal with this patch. I think this patch is a small improvement. We do a bit more work in the shader instead of on the CPU and I find passing edges to the vertex shader less ugly than the old quad vertex hack. What do you think? Should we land this or not? I think it's good idea. And I'd like to follow up with some improvements to ShaderChromium.cpp that avoids some of the shader code duplication we currently have there. Btw, are there other layer types that need anti-aliasing too? Video and Plugin layers?
Created attachment 108670 [details] Patch