tree 9cd573c206571218477e4119b97565047ebe5252
parent ac8fe134de58e6aa3c280a24fae0bcde8f7990c5
author senorblanco@chromium.org <senorblanco@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> 1342203906 +0000
committer senorblanco@chromium.org <senorblanco@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> 1342203906 +0000

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