←back to thread

591 points consumer451 | 5 comments | | HN request time: 0.691s | source
Show context
mbil ◴[] No.42161213[source]
This crashes my Safari browser on iOS.
replies(7): >>42161227 #>>42161294 #>>42161301 #>>42161743 #>>42162962 #>>42163108 #>>42174356 #
yazzku ◴[] No.42161301[source]
"Works" on Firefox if you can stomach 300-400ms pauses every 2 seconds.

Edit: I just profiled it and it spends 42% of exclusive time in texImage2D. It would be better to allocate a set of textures up front and then use glTexSubImage2D to update their contents. glTexImage2D allocates a new texture every time.

replies(1): >>42161377 #
1. theoretically23 ◴[] No.42161377[source]
Thanks - should be better now hopefully on Firefox
replies(2): >>42161678 #>>42165640 #
2. DaiPlusPlus ◴[] No.42161678[source]
Still very stuttery before crashing in Safari on iOS on my iPad :/
replies(1): >>42165150 #
3. brookst ◴[] No.42165150[source]
Smooth and stable on iOS DB3 on iPad…
4. yazzku ◴[] No.42165640[source]
This did get rid of that bottleneck and the stutters are slightly better, but it still has some more work to go.

https://ibb.co/LgtJHMs

You'll want to get rid of glTexImage2D completely except for application startup (allocate a pool of N images up front, then re-use them and update with glTexSubImage2D). And short of being able to optimize the text render, which seems to be awfully stupid, you'll want to render offscreen to those textures ahead of time before you need to render them on-screen.

replies(1): >>42167286 #
5. yazzku ◴[] No.42167286[source]
To be fair, you're crazy CPU-bound. This workload is peanuts for a modern GPU and there's no excuse for it not running at 500+ fps. But that's just how JS goes. You'd probably have better luck with C/wasm for this kind of thing if the web is your target.