Like for QR Code, precise maps or +100 pixels wide squares. More than 100 "DOM" elements and it will take multiple seconds to show.
The animations also are slow too, compared to canvas, plain CSS or Lottie but nothing very cursed, it's mostly fine.
Like for QR Code, precise maps or +100 pixels wide squares. More than 100 "DOM" elements and it will take multiple seconds to show.
The animations also are slow too, compared to canvas, plain CSS or Lottie but nothing very cursed, it's mostly fine.
This was done for a friend of mine who made an art installation that projected like some 50x20 (can’t remember exactly) of these images in a grid on a wall, for perpetual chess madness.
The number of chess SVGs a laptop’s browser was able to run simultaneously did feel suprisingly low, but luckily it was enough for that particular piece of art.
He said he used ipads as renderers. And even one grid may have looked different back in the day than that page now, as the font might be different. The SVG just uses system fonts and the chess pieces are just unicode characters.
You can increase COMP_MOVE_TIMEOUT (which is now 1 millisecond) to, say, 100 milliseconds.
RESET TIMEOUT defines how long the game is paused after game is finished to let the viewer to see the result, and NEW_GAME_START_TIMEOUT defines how long to wait before doing the first move when a new game is started.
The static image may be because of some browser security mechanisms; served as raw from GitHub the SVG is not animated for me either on Firefox, but when I download the SVG and view it from local drive in Firefox, it works. (It did work when served from GitHub at some point in history, though.)