New experimental SVG based goban renderer

Not the image tag itself, but using data urls - ie, pixel data we generate on the fly, which is what we’ve been doing for canvases.

… looking again this may not be the case, I might be confusing some things. At some point when I was doing that (Because that’s the first path I started down) I hit some problem, then some googling turned up javascript - Generating SVG files in browser now that data URLs seem to be deprecated? - Stack Overflow and 停止使用 SVG 元素中的数据网址  |  Blog  |  Chrome for Developers (the later of which is for the <use> tag not <image> tag, I missed that before) - so long story short, I don’t actually know what the status of using data within images is, it might actually be fine after all.

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.

2 Likes

Try shift-reloading?

image

is what I’m seeing on the production site at the moment

1 Like

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!

4 Likes

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.

2 Likes

log off, log in helped

image

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.

1 Like

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:

image

4 Likes

image

yes, its better now:
image

I think stones are too big, they collide into each other, illusion of third little object between 2 white stones appears


image

there were spaces between stones before in same window size

3 Likes

I haven’t noticed any static or noise when using img elements embedded in an the SVG rendered board of BesoGo.

If you are considering images for the Go stones, here’s a set of CC-licensed images that may be useful

3 Likes

also, AI review gone crazy

4 Likes

Technically, they’re too small: Equipment Dimensions at Sensei's Library - which has been a common complaint for years :slight_smile:

2 Likes

Thanks for catching that, I thought I had that working right, I’ll get it fixed up in the morning

2 Likes

image
when I move ghost stone cursor on blue circle or actual move circle, it becomes black

image

image

it doesn’t become black on green square
image

2 Likes

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.

4 Likes


they literally bump into each other and stones on the edge of board are cut

2 Likes

hoshi (star) points are too small

9 Likes

It appears overlap happens only when black stones are involved.


Screenshot 2024-05-23 at 4.11.07 PM
Screenshot 2024-05-23 at 4.15.32 PM

Is OGS doing that thing where black stones are larger to counter the irradiation illusion?


Update: I looked at the code, and haven’t found anything to that effect. Also it’s not a problem with all themes. I’m stumped! :person_shrugging:

4 Likes

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.

4 Likes

Hm this problem seems persistent…

It’s difficult to follow a review with this
image

It messes up my mind’s order of whose turn it is.

2 Likes

is your hoshi also too small for 19x19 and very very too small for 9x9?

I didn’t notice, the goban feels a bit needs-to-get-used-to, because the colours are different, so I’m not sure.