OrbitControls effective rotate speed changes based on screen aspect ratio

[dustinkerstein]

This is more of a design decision, but I figured I'd add it as a bug for discussion's sake since it was causing some issues for my implementation.

The rotate functions currently take into consideration the screen size through the use of element.clientHeight/Width:

// rotating across whole screen goes 360 degrees around
rotateLeft( 2 * Math.PI * rotateDelta.x / element.clientWidth );

// rotating up and down along whole screen attempts to go 360, but limited to 180
rotateUp( 2 * Math.PI * rotateDelta.y / element.clientHeight );

But this means that on non-square screens, the effective speed is different in the Up/Down vs. Left/Right directions. Ie. Try drawing a circle when your screen is a very wide/tall rectangle. You'll notice that you're effectively drawing an oval. To me it feels much more natural without the element.clientHeight/Width in the above equations (with the necessary tweaks to rotationSpeed). It seems like the comments are the explanation, but this results in awkward behavior for wide/tall screens. Is there some other benefit of having the screen size in this equation that I'm not seeing?

Three.js version

• [X ] r92

Browser

• All of them

OS

• All of them

[WestLangley]

Good point.

In handleMouseMoveRotate() and handleTouchMoveRotate() we could remove the comments and try this, instead:

rotateLeft( 2 * Math.PI * rotateDelta.x / element.clientHeight );

rotateUp( 2 * Math.PI * rotateDelta.y / element.clientHeight );

[dustinkerstein]

That helps with the aspect ratio, but I still find it odd to scale the speed with the screen size.

[WestLangley]

The factor must be unit-less.

[dustinkerstein]

Ah, yeah. I just played around with it some more and that makes sense.