aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/effects/SkTransparentShader.cpp
diff options
context:
space:
mode:
authorGravatar senorblanco@chromium.org <senorblanco@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81>2012-07-13 18:25:06 +0000
committerGravatar senorblanco@chromium.org <senorblanco@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81>2012-07-13 18:25:06 +0000
commitf4770d7e841a34d74d7f76a33312f4c5624da831 (patch)
tree9cd573c206571218477e4119b97565047ebe5252 /src/effects/SkTransparentShader.cpp
parentac8fe134de58e6aa3c280a24fae0bcde8f7990c5 (diff)
There were three different problems with lighting filters:
1) Texture offsets (fImageIncrement) have to be signed depending on whether the texture is "right way up" (texture upload) or "upside down" (render target), so the surface normals were coming out upside down. 2) Light normals have to y-negated on upload These two bugs were cancelling each other out in SampleApp, (where we were testing w/textures) but not in Chrome (where we were testing w/render targets). 3) The extract-the-height-from-the-view-matrix hack I was using to compare light positions vs. gl_FragCoord doesn't work in Chrome where we compile with GR_STATIC_RECT_VB, and the view matrix contains more than the viewport transform (to accomodate the canonical vertex buffer). Fixed by passing the destination render target to GrGLProgramStage::setData(), so it can flip the light positions in Y on the CPU. Review URL: http://codereview.appspot.com/6343109/ git-svn-id: http://skia.googlecode.com/svn/trunk@4605 2bbb7eff-a529-9590-31e7-b0007b416f81
Diffstat (limited to 'src/effects/SkTransparentShader.cpp')
0 files changed, 0 insertions, 0 deletions