WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
65483
[chromium] Move layer anti-aliasing code to vertex shader
https://bugs.webkit.org/show_bug.cgi?id=65483
Summary
[chromium] Move layer anti-aliasing code to vertex shader
David Reveman
Reported
2011-08-01 13:35:56 PDT
Move as much as possible of the edge intersection and vertex offset code used for layer anti-aliasing to the vertex shader.
Attachments
Move edge intersection code used for anti-aliasing to shader.
(24.61 KB, patch)
2011-09-01 17:15 PDT
,
David Reveman
no flags
Details
Formatted Diff
Diff
Patch
(705.87 KB, patch)
2011-09-07 13:44 PDT
,
David Reveman
no flags
Details
Formatted Diff
Diff
Patch
(706.01 KB, patch)
2011-09-09 10:28 PDT
,
David Reveman
no flags
Details
Formatted Diff
Diff
Patch
(705.18 KB, patch)
2011-09-13 10:34 PDT
,
David Reveman
no flags
Details
Formatted Diff
Diff
Patch
(705.54 KB, patch)
2011-09-26 08:30 PDT
,
David Reveman
no flags
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
David Reveman
Comment 1
2011-08-18 11:15:05 PDT
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?
David Reveman
Comment 2
2011-09-01 17:15:29 PDT
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.
David Reveman
Comment 3
2011-09-07 13:44:31 PDT
Created
attachment 106628
[details]
Patch
David Reveman
Comment 4
2011-09-09 10:28:40 PDT
Created
attachment 106886
[details]
Patch
Adrienne Walker
Comment 5
2011-09-12 13:15:38 PDT
(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).
David Reveman
Comment 6
2011-09-13 10:34:15 PDT
Created
attachment 107191
[details]
Patch
David Reveman
Comment 7
2011-09-13 10:53:56 PDT
(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?
David Reveman
Comment 8
2011-09-26 08:30:33 PDT
Created
attachment 108670
[details]
Patch
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug