shuding
Slow performance on mobile
I created a globe on this draft of a new SvelteKit homepage: https://kit-svelte-4iwujf16y-svelte.vercel.app/
When I pull it up on mobile, it makes the page laggy and temporarily locks up my phone. I confirmed with another maintainer who also has a high-end phone.
I think it should be possible as I noticed https://stripe.com/blog/globe works fine on my phone.
I'm not sure if I've done anything obviously wrong. You can see my code here: https://github.com/benmccann/kit/blob/2c2ff26d0c2765571977d46a54602f3b08dc130d/sites/kit.svelte.dev/src/routes/Grow.svelte
Yeah I noticed the same performance issue. I'm wondering if it's because the canvas dimension being too large? Currently it's 1800x400 with DPR=2 (3600x800) even on mobile. Could you try changing it to fit into window.innerWidth?
Ah, yeah, that could be. I'm trying to change it, but can't really make sense of the dimension settings. Why does the example set width and height twice? (once via width property and once via style property). It also seems like the library is updating the canvas element to change some of the dimensions I'm specifying. Can I use dimensions that change? Like 100% of the page width? Will the globe resize as I resize the page in that case?
@RoberOrz in latest version, you can pass context: { antialias: false } as per #47.
@benmccann
Why does the example set width and height twice?
Because the HTML canvas itself requires width and height to know how many pixels it should render. And then there is CSS width and height to let the browser show it on screen. So in your case style="width: 500px; height: 500px" makes it like a 500x500 picture on screen, and width="1000" makes the actual image computation base on the 1000x1000 canvas (2x), so the image is clear on a high device pixel ratio screen (which is most screens have nowadays).
And then, because the viewport size can change any time and to always maintain a 2x ratio, you have to add event listeners to resize and then set width and height for the globe just like all the examples do.
I'm gonna close this for now as the performance issue is more related to the canvas and webgl itself, not specifically to this lib's code.