We Keep Coding

Three.js slow on phone's vertical screen

I have this codepen that I made into a website. My problem is that it performs really slowly on the Chrome browser on my Nexus 5X phone, but when I rotate the screen to horizontal view or when I view the CodePen it runs smoothly again.
I've tried reversing the width and height to see if it was a screen / window height problem, and I've tried decreasing the height by a lot but it still is the same.
Will someone who is more experienced in webgl or three please explain this to me?
function init() {
scene = new THREE.Scene();
height = window.innerHeight;
width = window.innerWidth;
aspectRatio = width / height;
// ...
}

You may need to include some resizing logic in your render loop since the initial window size may change after loading (i.e. when rotated).. and if the window size changes but the renderer is not resized, then the renderer will be rendering to a nonintuitive framebuffer size and may cause problems when trying to scale the output to the actual display.
Edit:
I'm just throwing out guesses. :D And you make good points...
I do see that TODO line 36 Of your index.js.. which could cause problems.. Aside from that everything else in there looks legit to me.
Resizing logic can be tricky, because depending on CSS etc. setting the renderer size, can cause a pathological cascading resize since setting the renderer size, changes the camera size, which can cause a layout change.. and in some strange circumstances can cause small resizes to happen constantly.
Another way to check if this is the problem, is just make your renderer a fixed size square in your init... like 256x256 or something.. and comment out the window.resize listener.. .run that on your phone and see if performance stays consistent on rotations... fwiw, I think i see the issue on my Galaxy S5.. in horizontal mode its super liquid but vertical mode.. seems a little pokey.

Hey are you using PMREMGenerator at all in the code?
I've noticed that using this to generate environment maps really chuggs on the phones in portrait mode

CSS transform on image getting pixelated

I'm resizing an image with setting the width/height dynamicly with css and using transform duration to smooth this process. However it is working but once the animation started the image gets pixelated. Occurs in Firefox and Chrome, i didnt test any other browsers.

Your height is fixed, before and after the resize, it could have something to do with it?
Try and amend the javascript to also set the final height of the div, if you want to maintain aspect ratio, see http://andrew.hedges.name/experiments/aspect_ratio/
from the initial 350x64 the final dimension should be 250x46

Android Tablet paper.js on zoomed canvas

I got problem on Android Tablet (Galaxy Tab 2). When having a big image, and using paper.js to draw paths on it, everything is fine, but when I zoom the image (only if it is big enough), paper.js stops drawing paths on a certain width and height... the image on canvas is still being displayed (background-image with width and height set to 100%), but it seems that paper.js is unable to draw farther than some width and height. Any idea what is going on or how to fix it?
If something isn't well explained, please give me feedback. I really need to get it working. Today.

-webkit-transform: scale breaks down when zoomed in on iOS

EDIT:
These issues appear to have been fixed by iOS8. Consider this issue an iOS7 and earlier bug.
I've got some content (subject to CORS) that I'm serving in an iframe, that I want to be always stretched across the bottom of the browser window. I need this content to keep the same aspect ratio and fill the entire width of the browser, otherwise things will look weird. Because I don't have access to the iframe's contents I'm using -webkit-transform: scale to properly size everything properly.
I'm calculating the scaleFactor:
width = 600; // this is the original width of the iframe's contents and never changes
scaleFactor = window.innerWidth/width;
Then I set some CSS based on that scaleFactor, whenever window.innerWidth changes size:
$container.css({
'width': (width * scaleFactor) + 'px',
'height': (height * scaleFactor) + 'px',
'padding': 0
});
$iframe.css({
'-webkit-transform': 'scale('+scaleFactor+')',
'transform': 'scale('+scaleFactor+')',
'-webkit-transform-origin': '0 0',
'transform-origin': '0 0'
});
This works perfectly everyplace except iOS where it starts to break down if you zoom in too far. The iFrame starts to drift off the page and isn't near wide enough. I have no clue what's going on here.
Images of what I'm talking about: Good scaling, Bad scaling.
I've got a test page setup here that clearly demonstrates the problem on any iOS.
Anybody have any ideas?

Here's the result of my extensive investigation before I gave up.
There are two major problems involved in applying transform: scale to content inside iframes on iOS. The first was what I pointed out in the original question, that content starts to drift away from it's specified location on the page if you are using fixed position elements. It works up to a point that seems to be based on the original size of the element, the scale factor, and presumably the viewport width. In my tests a large element might scale and position perfectly when scaled at any factor greater than 0.85. A small element might be positioned perfectly so long as the scale factor is at least >3.5. It seems almost random, so I didn't bother determining what the exact point was.
I didn't try this on relatively positioned elements, but I'm assuming they function similar to fixed position elements.
There is a rather kludgy workaround for this involving using absolutely positioned elements anchored to the bottom of the page using scroll offsets and innerHeight. i.e.:
container.css('top', (document.body.scrollTop + window.innerHeight - container.height()) + 'px');
container.css('left', document.body.scrollLeft);
And updating this on every drag, transform, pinch, resize, etc. There is some weirdness involved with this method (iOS doesn't update scroll offsets until after a drag has completely stopped) but it's workable if you absolutely had to do it.
However, even though that's a possibility, when you scale content inside iframes on iOS, if you have ANY anchor tags (or other elements that need to be clicked on), the clickable area stays unscaled. If you have an image in inside an anchor tag that's 200x100 and you scale it 2x, the image will be twice as big, but the anchor will only respond to the first 200x100. Using the iOS simulator, if you double click on an image outside the clickable area Safari is even helpful enough to darken the original bounds so you know where you could have clicked. It's pretty much a deal breaker if you want to display anything other than text/images that don't require clicking or other inputs. More information here:
CSS3 Transform scaling issue on IPad Safari
"-webkit-transform: scale(2)" doesn't affect click area of Facebook Like Button (on iPad)
Until Apple fixes these long standing bugs in mobile Safari, it seems that trying to scale iframe content using webkit-transform isn't a viable option unless you are only targeting Chrome.
Edit:
Demo of scaling issues here.

Combo of iframe, transform scale, and ios is tricky.
There are bugs with transform scale. Not always in your control.
You can try zoom property instead of scale, and use scale for firefox where its not supported.
I don't have ios here so I cant check but it often works wonders. Though you may have issues with line breaks in text with zoom.
zoom solves this bug in chrome

Scaled Transparent PNGs lose anti-aliasing after jQuery animation in Webkit browsers

I have a script that lays out these circular icons on the map, you hover over them, they spring up, text appears, etc. The icons are scaled relative to their position on the map, ie, the distance from 0 on the y-axis. I've tried to set the scale through CSS's width and height attributes and through the html width & heights on the img tag and still have the same problem:
Basically, in their dormant state, such as when the page is first loaded, or the user flicks between tabs, the images (trans' PNGs) are anti-aliased. However, when the hover() function, and thus the animate() function, is invoked, the images suddenly become jagged and horrid. I've noticed that this behaviour doesn't exist in firefox but does in safari and chrome. I don't know whether this is to do with Webkit, jQuery or just javascript itself but maybe someone could shine some light as google resulted in nothing. Any thoughts? :)
Please also note that the bottom left and bottom right icons look fine in both attached screenshots- they're unscaled ones!
Thanks a lot :)
Matt

i can only guess on this, but my assumption is that gecko and webkit use different scaling algorithms for images. thus it has nothing to do with javascript, jquery or png at all.
in fact, the image still has antialiased edges even in the webkit screenshot. (you see that when you zoom in)
the border is just messed up which is usually the result of a bad scaling algorithm.
try the following to confirm this assumption:
<img src="youricon.png" width="90%" height="90%">
and compare the result in the two browsers. you should see the same problem.
possible solutions:
make a smaller version of the image and replace image with the smaller one on hover instead of scaling it.
use a scalable vector graphics format like SVG for your icons.