Three.js Full Screen Issue

Question

I've read through the Three.js API, read through the questions here on StackOverflow, I've debugged the code using firebug and chrome's debugger, I've stripped out everything I can, but I am still getting this irritating full screen error, where the renderer view port is larger than my screen thus causing scroll bars to appear. It's a visible error that does not affect rendering, or other operations, I am just trying to control the size of the view port so that it matches available screen real estate without scroll bars appearing.

I am using Google Chrome 18 on Windows 7 and I am just starting to work with the Three.js API, but I have used things like OpenGL in the past so graphics API are not unfamiliar.

When I try and run this code (which is the default example shown on the github main page):

var camera, scene, renderer,
geometry, material, mesh;

init();
animate();

function init() {

    scene = new THREE.Scene();

    camera = new THREE.PerspectiveCamera( 75, window.innerWidth / window.innerHeight, 1, 10000 );
    camera.position.z = 1000;
    scene.add( camera );

    geometry = new THREE.CubeGeometry( 200, 200, 200 );
    material = new THREE.MeshBasicMaterial( { color: 0xff0000, wireframe: true } );

    mesh = new THREE.Mesh( geometry, material );
    scene.add( mesh );

    renderer = new THREE.CanvasRenderer();
    renderer.setSize( window.innerWidth, window.innerHeight );

    document.body.appendChild( renderer.domElement );

}

function animate() {

    // note: three.js includes requestAnimationFrame shim
    requestAnimationFrame( animate );
    render();

}

function render() {

    mesh.rotation.x += 0.01;
    mesh.rotation.y += 0.02;

    renderer.render( scene, camera );

}

It renders fine, I see the red wire frame box rotating around, but I've noticed that the renderer view port is too big, it is larger than my available screen size, which causes scroll bars to appear. The code uses window.innerWidth and window.innerHeight to set the aspect ratio and the width/height for the renderer, but it seems as if it picks up 20 to 30 extra pixels somewhere and adds them to the bottom and the right of the page?

I've tried adjusting the CSS for the body element to remove margin and padding, same for the canvas element that gets created, but nothing. I've echoed the screen size to the page, and made JavaScript alert() functions to check the window width and height, and then watch as they get passed to the Three.js API during runtime operations, but the error remains: the canvas rendering object is resizing itself to slightly larger than the screen size. The closest I get to correcting the problem is doing something like this:

var val = 7;
//Trims the window size by val
function get_width(){return window.innerWidth - val;}
function get_height(){return window.innerHeight - val;}

//... Code omitted for brevity

camera = new THREE.PerspectiveCamera( 75, get_width() / get_height(), 1, 10000 );

//... Code omitted for brevity 

render.setSize(get_width(), get_height());

It works to bring the renderer size within the boundaries of the window, but only to a point. If I lower val to less than 7, e.g. 6 or less, the renderer size pops back out and is again larger by 20 px (approx), than the screen, causing the scroll bars to appear?

Any thoughts or ideas?

Solution 1

Simply set display: block; on canvas element in your CSS

The <canvas> element is according to the mozilla developers network officially a block-level element. Something in between a inline element and a block element. They write:

Browsers typically display the block-level element with a newline both before and after the element.

But rendering of the element can vary across browsers, so to be sure you get the correct behavior it is best to explicitly set display: inline; or display: block; in your CSS.

So just set its display value in your CSS file to block, to solve the issue.

canvas {
    display: block; /* fix necessary to remove space at bottom of canvas */
}

Solution 2

I. Viewport Size Accuracy

I recommend using viewportSize.js by Tyson Matanich, since 'window.innerWidth' and 'window.innerHeight' are not always accurate.

Download : https://github.com/tysonmatanich/viewportSize

Demo : http://tysonmatanich.github.com/viewportSize/

Here's a detailed explanation from the author :

"Most people rely on window.innerWidth, document.documentElement.clientWidth, or $(window).width() which do not always accurately report the viewport width used in CSS media queries. For example, WebKit browsers change the size of their CSS viewport when scroll bars are visible, while most other browsers do not. Since window.innerWidth remains constant regardless of the scroll bar state, it is not a good option for use with Chrome or Safari. Additionally, Internet Explorer 6, 7, and 8 do not support window.innerWidth. On the other hand, document.documentElement.clientWidth changes based on the scroll bar state and therefore is not a good option for Internet Explorer, Firefox, or Opera."

Example :

var viewportWidth  = viewportSize.getWidth(),
    viewportHeight = viewportSize.getHeight(),
    viewportAspect = viewportWidth / viewportHeight;

camera = new THREE.PerspectiveCamera( 75, viewportAspect, 1, 10000 );

II. Elusive Elements

Look out for any elements created programmatically (via 'createElement'). They are easy to miss.

Use Chrome's inspector, or Firebug to see if there are any other elements that you might have missed. Often I see something that I had totally forgotten about, buried deep in last week's code and wonder how the heck I had missed it before.

III. Hard Reset

Lastly, to be thorough, you can try a hard reset. Eric Meyer's classic reset is generally considered to be the most thorough (http://meyerweb.com/eric/tools/css/reset/index.html), but I personally prefer the 'Condensed Meyer Reset' (which surfaced on the web sometime last year, author unknown) :

body, div, dl, dt, dd, ul, ol, li, h1, h2, h3, h4, h5, h6, 
pre, form, fieldset, input, textarea, p, blockquote, th, td { 
    padding: 0;
    margin: 0;
    }
fieldset, img { 
    border: 0;
    }
table {
    border-collapse: collapse;
    border-spacing: 0;
    }
ol, ul {
    list-style: none;
    }
address, caption, cite, code, dfn, em, strong, th, var {
    font-weight: normal;
    font-style: normal;
    }
caption, th {
    text-align: left;
    }
h1, h2, h3, h4, h5, h6 {
    font-weight: normal;
    font-size: 100%;
    }
q:before, q:after {
    content: '';
    }
abbr, acronym { 
    border: 0;
    }

Comments

[ultrafez]

This should be the accepted answer - hiding the overflow just masks the problem, but this fixes it. Thanks very much!

[Charles HETIER]

I agree with ultrafez, moreover, by click dragging the mouse on the window, even if the scrollbar is hidden, the content is still scrolling!...

[hypervisor666]

As I'm still getting hits on this question 4 years later, I've accepted this answer based on the advice of ultrafez, and the community upvotes of this answer, thank you @Wilt for providing the updated answer!