Performance drop in mobile portrait mode (Andoird; Chrome, Firefox...)

performance

#1

(First time here, so please let me know if there’s anything wrong with this post.
Also, I’m not an experienced programmer.)

I’ve been getting performance drop in mobile (Android) that only happens in portrait mode.
Project runs fine in desktop and in landscape mode in mobile.
Another weird thing is that this happens with Chrome and Firefox, however it doesn’t in Fullscreen Browser (an app for fullscreen browsing).

It happens even in this simple example:
(click left/right side of screen to rotate camera accordingly - rotates smoothly, except in cases mentioned above)

var scene = new THREE.Scene();
var camera = new THREE.PerspectiveCamera( 75, window.innerWidth/window.innerHeight, 0.1, 1000 );

var renderer = new THREE.WebGLRenderer();
renderer.setSize( window.innerWidth, window.innerHeight );
document.body.appendChild( renderer.domElement );
renderer.shadowMap.enabled = true;
renderer.shadowMap.type = THREE.PCFSoftShadowMap; // default THREE.PCFShadowMap

//Chao
var geometry = new THREE.BoxGeometry( 100, 1, 100 );
var material = new THREE.MeshLambertMaterial( { color: 0xffffff } );
var chao = new THREE.Mesh( geometry, material );
scene.add( chao );
chao.receiveShadow = true;

// Cubo1
var geometry = new THREE.BoxGeometry( 1, 1, 1 );
var material = new THREE.MeshLambertMaterial( { color: 0xffffff } );
var cube = new THREE.Mesh( geometry, material );
scene.add( cube );
cube.position.y = 2;
cube.castShadow = true;

var ambientLight = new THREE.AmbientLight(0xffffff,0.5);
scene.add(ambientLight);
var spotLight = new THREE.SpotLight(0xffffff);
spotLight.position.set(0, 20, 8);
spotLight.castShadow = true;
scene.add(spotLight);

camera.position.y = 2;
camera.position.z = 5;

window.addEventListener('deviceorientation', function(e) {
  ube.rotation.x = e.alpha/100;
 cube.rotation.y = e.beta/100;
 cube.rotation.z = e.gamma/100;
});

var x, y;
var pressed=false;

window.addEventListener( 'mousedown', onTouchStart );
window.addEventListener( 'touchstart', onTouchStart );
function onTouchStart( event ) {
	if ( event.changedTouches ) {
		x = event.changedTouches[ 0 ].pageX;
		y = event.changedTouches[ 0 ].pageY;
	} else {
		x = event.clientX;
		y = event.clientY;
	}

pressed=true;
	
}
window.addEventListener( 'mouseup', onTouchEnd);
window.addEventListener( 'touchend', onTouchEnd );
function onTouchEnd( event ) {
	
pressed=false;
	
}
		

var animate = function () {
	requestAnimationFrame( animate );

if(pressed){
	if(x<window.innerWidth/2){	
		camera.rotation.y += 0.02;
	}else{
		camera.rotation.y -= 0.02;	
	}
}	
	
	renderer.render(scene, camera);
};

animate();

#2

Do you have this performance drop only with your own apps or also with other WebGL applications? For example:

or

threejs.org/examples/


#3

Thanks for quick reply!

It does not happen with these examples. I did notice that before, but since my scene was so simple I just assumed it was some very specific bug.

Now I realize I should have made more tests before assuming that.

I just did some tests, starting from a basic scene showing a rotating cube (which performs fine regardless of platform/screen orientation), and gradually adding features and testing on mobile. I found that the performance drop happens when I add a PCFSoftShadowMap (doesn’t happen with default shadow).

This solves my specific issue, as I can just use basic shadows.

///

But now I’m curious. Why does the orientation of the screen affect performance so much when that particular type of shadow is present? (I’ll elaborate below - let me know if I should post this as a separate question, or as a bug report).

At first I thought it could be due to the fact that the cube occupied a bigger screen area when in portrait mode, which in turn would make the shadow bigger (and thus requiring more calculations to soften it).

However I did another test with the camera zoomed in, to make the cube appear just as big in landscape mode, and performance is still normal in that orientation. (Also, it still seems weird that this would happen with Chrome and Firefox, and not the FullScreen Browser app I mentioned before…)

Any thoughts?


#4

Not really :wink:. The only thing I can say for sure is that PCFSoftShadowMap requires much more calculations in the fragment shader than just PCFShadowMap (default).