This is an interesting write up - I had assumed that devicePixelRatio * dimension would always get you to physical pixel size of the screen but it seems that’s not the case. I’m on a Macbook with OS 15.6.1 and after changing some system display settings I’m unable to get the render buffer size to exceed the physical pixel units size. The “devicePixelRatio” is always either 1 or 2 (when connected to an external monitor) but it’s alway the case that devicePixelRatio * innerWidth is <= the real monitor pixel width, so there’s no performance issue.
It seems like this is specifically an artifact of how your linux distribution handles UI scaling? As in it’s always rounding the reported “pixel ratio” up to an integer even though the resolution has only been scaled by a fraction. I’m wondering how widespread this issue is or if it’s limited to non-standard OSs?
–
One maybe somewhat related issue I’ve noticed is that zooming the page in and out (cmd + +/-) can majorly impact performance because this changes the DPR and triggers a resize but three.js does not set the DPR in any of the resize callbacks. This leads to cases where the DPR was set to 2.0 on page load but once scaling, the window width is reported as 7200 so three.js starts rendering to a 14400 canvas. If the renderer correctly adjusted the DPR to 0.5 on resize, as well, then it would render to the appropriate 3600-pixel-width physical resolution.