Browse Source

Fix sample for machines with devicePixelRatio > 1

This is arguably exactly why WebGL doesn't adjust the resolution
automagically for HD-DPI displays. BECAUSE IT BREAKS STUFF!

The program asked for a renderer with a specific size but three.js
actually made the canvas some other size. That breaks any app
that doesn't know it has to query the size after three as arbitrarily
decided to make the canvas some other size.

It gets worse if the user's shaders are doing any calculations
based on say gl_FragCoord.  For example if you did this

    gl_FragColor = vec4(mod(gl_FragCoord / 100, 2), 0, 1);

and you called

    renderer.setSize( 200, 200 )

The user would expect to get a 2x2 checkerboard but if WebGL or
in this case three.js actually makes the canvas some other size
his program is broken. It no longer makes what he asked for
or was intending to make

It's for this reason WebGL doesn't automatically make the canvas
a different size than requested. I'd argue three.js should follow
the same logic.

On top of that far more people have HD-DPI phones than HD-DPI
desktops, at least as of today. Phones have slow GPUs so automatically
uping three.js app to 4x or 6x the pixel seems like maybe not the
best idea. You end up forcing every app to work around three.js if they
want to be mobile friendly

Just a thought.
Gregg Tavares 10 years ago
parent
commit
ba5a121799
1 changed files with 3 additions and 3 deletions
  1. 3 3
      examples/webgl_shader.html

+ 3 - 3
examples/webgl_shader.html

@@ -142,11 +142,11 @@
 
 			function onWindowResize( event ) {
 
-				uniforms.resolution.value.x = window.innerWidth;
-				uniforms.resolution.value.y = window.innerHeight;
-
 				renderer.setSize( window.innerWidth, window.innerHeight );
 
+				uniforms.resolution.value.x = renderer.domElement.width;
+				uniforms.resolution.value.y = renderer.domElement.height;
+
 			}
 
 			//