Anyways, the static problem I think would persist regardless, the problem with that one is some browsers, when in privacy mode, inject static or other bad data into canvases when you read from them or even just copy them into other canvases, since doing such a thing is a technique some nefarious folks use to identify small inconsistencies to be able to fingerprint browsers. So instead of fixing their glitchy inconsistent rendering systems, they just trash the output to thwart the bad apples, despite it damaging sites that are just trying to draw stuff on the screen.
The other problems is some mobile browsers (Safari) have issues where sometimes canvas allocations will fail, even after only a few allocations. Other times it’ll be fine for hundreds of canvases. I suspect this is a low memory or memory leak issue outside of our browser sandbox, but I don’t know for sure, it’s a pretty rare bug but causes rendering issues obviously.
I think we could theoretically bypass uses canvases all together and create the data blobs ourselves, but that requires implementing the canvas drawing primitives we use and encoding stuff into a data string in whatever format it needs (which would probably be pretty easy as a bmp if that’s possible).
Anyways, it’s certainly a possibility, but not a cheap and easy one.
Ha, you’re right, it’s just the Anime ones that are laggy (maybe it has a hard time rasterizing all those shadows / semitransparency). Chrome / Mac / MBP M1 Pro. The shell ones are fast.
BTW, the SVG stones look much better now, so good work with the tweaking!
Interesting thanks for checking and following up with that. The main difference with those ones is they’re loaded from a url, so I wonder if something is wonky and not getting cached right or something, I’ll look into it.
Slightly better. but I still able to see that circle is made of pixels. While old stones were truly circles without corners. Its like ClearType in font was turned off.
I figured out what we’re seeing there, there’s a circle (black) underneath the stone that does the actual shadow cast, I had it the same radius as the stone, so the svg anti-aliasing was actually “seeing” some of it and that’s where the outline and hard edges were coming from.
Reload (shift-reload, or cmd-reload, or whtaever it is) and it should be better now:
It’d be specifically related to reading pixels from a canvas, normal images in svgs should work great
I hadn’t been, I was considering using the rendered canvas data… however I’m starting to think maybe it’s time to switch to images for some options, in particular for the shell and slate stones, and maybe add an option for yunzi stones.
I believe that’s coming from the stroke, which hasn’t been consistent across browsers / platforms. The blue move is rendering terribly on his platform too because of that. I think the miniature hoshi is an artifact of some combination of HDPI and scaling settings on the device.