[tomxor]

Shameless plug.. I made a super slow motion 184 byte aperture grille (Trinitron) animation:

https://www.dwitter.net/d/12335

And a more recent one with more interesting motion at faster speed:

https://www.dwitter.net/d/21705

It is interesting how even as an animation it makes it look a lot smoother than the raw upscaled pixels of the same simple graphics.

[codetrotter]

The second one does not run for me on an iPhone X, but the first one does.

[tomxor]

I can only speculate as to why because it's safari which i don't have. If the eval is throwing an exception it's probably something to do with the unicode encoding that packs 2 ASCII chars into each UTF16 surrogate pair - the second one ultilises slightly more of the 20bits available and some UTF16 implementations/interfaces are buggy.

You could replace 'eval' with 'throw' and see if the output looks like sane JS

[bronson]

Output from iphone 11 seems to confirm your theory: https://dpaste.com/GU8A3X4H7#wrap

[tomxor]

Hah, actually that code is correct (Although I realise it probably looks like gobbledygook :D) so it disproves my theory.

The code is mostly arithmetic, so the only thing I can see which could be implementation sensitive is the canvas fillStyle HSL string, which omits commas and spaces since the % postfixes are enough to delimit the saturation and luminance, but obviously this depends on the canvas interface implementation.

[codetrotter]

I looked into it and this turned out to be the problem exactly.

If you change the part of your code where you have

  hsl(${i*120} 99%${K*99}%

To instead

  hsl(${i*120} 99% ${K*99}%

(That is, by not omitting the space after 99%)

Then it works in the versions of Safari that I tested; Safari 14.0.3 on macOS Big Sur 11.2.2 running on a MacBook Pro M1, and Safari on iOS 14.4 running on an iPhone X.