[Libreoffice-commits] core.git: slideshow/opengl

[Tor Lillqvist]

 slideshow/opengl/dissolveFragmentShader.glsl |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit 04352b481cc711dd2f9c345f69fb6a22a585cd29
Author: Tor Lillqvist <tml at collabora.com>
Date:   Sun Nov 8 16:52:39 2015 +0200

    Now I understand why that multiplication by 10 was there originally
    
    I was suffering from one basic misunderstanding: I did not get it that
    samplers are indexed with normalized texture coordinates, i.e. 0..1.
    (Note that multiplying a coordinate by any number does not break
    anything horribly for this use case, looking up a pseudo-random
    number, because textures by default repeat as a coordinate wraps.)
    
    We multiply by 10 so that neighbouring pixels that map to close index
    into the permTexture don't get clumped together with close sn values,
    and thus same behaviour.
    
    (Sure, the multiplication by 256 that I had changed it to worked, too,
    but not the way my initial reasoning went... So let's use the original
    10 to avoid somebody else thinking that we need to multiply by 256
    because permTexture is built from a 256x256 array.)
    
    (See 1877228ae8e7cc298cf4e45d061ee54774aa1d08)
    
    Change-Id: I1d350446460fe2fdd3e55f00053a5ce01d2d117c

diff --git a/slideshow/opengl/dissolveFragmentShader.glsl b/slideshow/opengl/dissolveFragmentShader.glsl
index 6ce3d53..c0fdbf4 100644
--- a/slideshow/opengl/dissolveFragmentShader.glsl
+++ b/slideshow/opengl/dissolveFragmentShader.glsl
@@ -40,7 +40,7 @@ float snoise(vec2 P) {
 }
 
 void main() {
-     float sn = snoise(256*v_texturePosition);
+     float sn = snoise(10.0*v_texturePosition);
      if( sn < time)
          gl_FragColor = texture2D(enteringSlideTexture, v_texturePosition);
      else