title: Three.js webgl renderer for high DPI displays bug?
body: <p>I have the following logic to create a Three.js R69 WebGL renderer that is supposed to handle high DPI displays. It did for quite a while, but about a week ago one and only one three.js page started rendering like the high DPI was correctly set, but my 3D coordinate origin became the upper left corner of the rendering canvas rather than the expected center of the canvas. (No changes to my environment that I can tell, maybe the browsers auto-updated. I'm testing with Chrome, FF and Safari on OSX 10.10.1)</p>
  
  <pre><code>// create our renderer:
  gCex3.renderer = new THREE.WebGLRenderer({ antialias:true, alpha:true,
                                             devicePixelRatio: window.devicePixelRatio || 1
                                          });
  // Three.js R69: I started needing to explicitly set this so clear alpha is 1:
  gCex3.renderer.setClearColor( new THREE.Color( 0x000000 ), 1 );
  gCex3.rendererDOM = $('#A3DH_Three_wrapper');
  gCex3.rendererDOM.append( gCex3.renderer.domElement );
  // fbWidth &amp; fbHeight are w,h of a div located within the page:
  gCex3.renderer.setSize( gs.fbWidth, gs.fbHeight, true ); // 'true' means update the canvas style
  </code></pre>
  
  <p>Checking the latest R69 examples, they don't seem to do anything special for high dpi displays. Checking the WebGLRenderer source, it looks like the devicePixelRatio logic is now embedded within the WebGLRenderer() function.</p>
  
  <p>I've tried that minimal logic in the examples, specifically this:</p>
  
  <pre><code>renderer = new THREE.WebGLRenderer( { antialias: false } );
  renderer.setClearColor( new THREE.Color( 0x000000 ), 1 );
  renderer.setSize( gs.fbWidth, gs.fbHeight, true );
  </code></pre>
  
  <p>And I see the same behavior: my coordinate system origin is the upper left of the rendering canvas.</p>
  
  <p>Note that in Chrome, when running the javascript debugger, I see a "webgl context lost" event during the exiting of the previous page, but before this logic is being executed. Could the WebGLRenderer be getting created during the period when there is no WebGL context? </p>