Issue 1:
Description of the problem

Given 2D geometry like

var vertices = new Float32Array( [-1,0, 0,1, 1,0, 0,-1, -1,0] );
var geometry = new THREE.BufferGeometry();
geometry.addAttribute( "position", new THREE.BufferAttribute( vertices, 2 ) );

I get the following console error (via render -> projectObject -> intersectsObject):

THREE.BufferGeometry.computeBoundingSphere(): Computed radius is NaN. The "position" attribute is likely to have NaN values.

I've only started playing with three.js today so I may be doing something derpy, but it looks like the problem is that computeBoundingSphere assumes 3 components per vertex and so unconditionally calls

position.getZ( i )

and that method returns

this.array[ index * this.itemSize + 2 ];

So each 2-component primitive uses a spurious z from the following primitive's x, and the last one falls off the end and gets NaN.

It doesn't seem to affect rendering and could presumably be avoided by setting the bounding sphere manually, but I'm guessing this wasn't intentional.

Fiddle demonstrating console error, dev is the same.

Three.js version

Dev

r87

...

Browser

All of them

Chrome

Firefox

Internet Explorer

OS

All of them

Windows

macOS

Linux

Android

iOS

Hardware (graphics card, VR Device, ...)

Intel HD Graphics 3000

Issue 2:
So, apparently many WebGL samples including three.js samples are broken on Safari and Chrome on the new iMacs with 5k displays.

The issue is the apps request a fullscreen canvas which is 5120x2880 but Chrome and Safari often return a 4096x2880 canvas. See bug report. So what happens is because the app asked for 5120x2880 it sets the gl.viewport to that but because the drawingBuffer is actually 4096x2880 it's the wrong viewport setting (and the wrong aspect ratio given the way most of the examples are not using clientWidth/clientHeight) and so the samples don't work.

As it says in the bug this is spec compliant. Basically you can ask for a canvas of any size and WebGL will do its best but the size you actually get is in gl.drawingBufferWidth and gl.drawingBufferHeight.

The question is, should three.js and the examples change to handle that?

Basically after you call renderer.setSize you need to check what size you actually got by checking gl.drawingBufferWidth and gl.drawingBufferHeight (could be some func like renderer.getSize) and then use those values in your code where appropriate. At the same time you should use gl.canvas.clientWidth and gl.canvas.clientHeight for your aspect ratio because the two won't match

NOTE: If you're curious why it's this way imagine you have a machine with 3 monitors side-by-side. Take any three.js sample and resize the window until it crosses and fills all 3 monitors. Let's assume the monitors are 1920x1080. You'll now have a window that's 5760x1080. The code will ask for a canvas 5760x1080 but the driver likely has a limit of 4096. So, rather than crash the spec says the canvas will have its width set to 5760 (so it fills the area of the page it's supposed to fill) but WebGL will make drawingbuffer whatever size it can. In this case probably 4096x1080.

Apparently they will look into the issue and see if they can make it return the fullsize on iMac 5k more often but (a) I went into the Apple store to test. It's not a hard coded limit AFAICT. Sometimes the samples work. Other times they don't. That suggests is a memory issue. 5120*2880 is 56meg. Antialiased that's at least 112meg, it's double buffered so that's 168meg, and then there's all the compositing tiles (b) even if they fix it so it happens less often it can still happen if your system is low on memory or if you have multiple monitors so it's still worth considering.

Thoughts?