screenshot of 9x9
yes, when window size is small, my hoshi are same small size.
when 9x9 is full screen zen mode, size is still identical and it becomes to look ridiculous
while on old board hoshi are bold even on small window
2 Likes
The hoshi and lines should scale better now. I also fixed the sub-triangle positioning so it doesnāt collide with the score change estimate in the reviews.
9 Likes
<whimper>
I was only able to read this diagonally, and while it seems that some are content with whatever fixes happened re: colours and shadows, for me even shift-reloading didnāt give me back the relatively mild contrasts I had before ā¦ turned the new experimental SVG thing off, shift-reload, and on again, ditto, rinse, repeat ā¦ nothing: shadows gone, white stones too bright and perhaps a little too blurry (?), a pain in the eye ā¦ and Iāve tried all the other stone options.
</whimper>
macOS 14.5, latest Safari ā¦ will
Can you take a screenshot?
1 Like
Huh, Iāll try and figure out whatās going on, all my shadows are working over here 
1 Like
Lemme know if I can help w/ diagnosing.
Is the SVG stone option set supposed to appear anything like the standard ones?
It appears to me like a āwhole lot of different stonesā ā¦ and Iām faced with ābut I like the stones I hadāā¦
4 Likes
I suspect this isnāt what the stone select options are supposed to look like? (Persists through page refresh / new tab)
Pixel 6
Android 14
GrapheneOS 2024052100
Vanadium (Chromium) Version 125.0.6422.113.0
9 Likes
Yeah me too, but no not at this point. Iām going to try out sampling some real shell stone images, and I think I might have some of the stones rendered as before, and so long as there are options, if those stop working or appear as static for some folks, at least there are other things that theyād be able to choose.
Interesting, yep sure not supposed to look like that 
3 Likes
I think that there is some low-hanging fruit to optimize the implementation. While the SVG uses groups, it appears that for each stone a new group is created.
Also, when a mouse hovers over the field, itās more performant to modify a style of a stone than SVG DOM. For example, there can be a dedicated group for the hovering stone that gets its transform and display attributes adjusted.
Also, each path element in the rendered-stones.ts preRenderWhiteSVG grows larger with the iteration. That seems to be a bug because the paths overlap.
6 Likes
Those sound like the words of a person well-placed to submit the solution 
3 Likes
Iād be curious to try, but I feel more confident about the svg itself than the TS code of the renderer. Since you are open to contributions, Iāll assume that the recently merged svg code is stable and try to find time to contribute and do measurements.
Also, I just looked deeper at the code, and it seems that I was mistaken about new stones getting created for each move - the svg had many definitions for another reason - the pre-rendered stones are created for each size in many variations.
4 Likes
So each intersection has a group that contains the stone, shadow, and any markings (score, letters, etc). Thatās mainly a convenience so I can easily remove and rebuild that group when I need to redraw an intersection.
Is that a bad practice? (Keep in mind this is a generated SVG, not a file so weāre optimizing on minimizing DOM changes as the board state is changed and overall rendering speed, as opposed to file size or something like that)
Are you seeing performance problems with the current solution? I definitely think thatād be faster, but for various reasons, itās a bit more complicated to do with how things work and all of the cases - so unless weāre seeing performance problems, I think Iād leave that particular inefficiency alone for the sake of simplicity.
Whoops, Iāll look into it. What theme are you seeing that on?
goban/src/Goban/SVGRenderer.ts at main Ā· online-go/goban Ā· GitHub if youāre interested. Itās probably the ugliest code in the whole project though, itās heavily derived from the canvas counter part which was pretty well optimized for speed for the canvas implementation.
I feel like with SVGs there has to be a cleaner way of doing the rendering in a performant way and just let the browser worry about making it fast, but at some level itās still about minimizing dom operations and the current code does that reasonably well I suppose.
4 Likes
For a regular game I donāt see the performance problems. I also completely agree that SVGās is a cleaner way than a canvas.
On my 4 year old laptop the scripting, rendering and painting took about 25% of time when quickly hovering the stone (as measured on the performance tab). Iād expect it to be worse on the older machines. Also, my point was exactly about minimizing the DOM operations rather than DOM size.
I ran a few experiments where I saved a <use> element for a stone from inspecting svg into a global variable and ran a few scripts that move the stone. I didnāt write a synthetic script to move the stone between the groups since goban already does that I could just jiggle the mouse and count the events.
If I a stone is moved by modifying the x attribute, the operations take 10% of the time (which is still high).
setInterval(() => {temp1.setAttribute("x", Math.random() * boardWidth)}, 100)
And if I use a transform, the operations take only 5%:
setInterval(() => {temp1.setAttribute("transform", `translate(${Math.random() * boardWidth})`)}, 100)
So, there is a room for speeding up hovering the stone by about x5. I see that as a win for the older machines.
Instead of just describing the theme issue here, I decided to open a PR. Thank you for the review and merging!
4 Likes
Thanks for delving into that and the detailed testing, seems worth it. Seems also likely if thatās true then it might be worth re-using old stones instead of removing and rebuilding as we skip around through moves.
3 Likes
Yeah, navigating the game tree can be rapid too, but I doubt that it is done continuously for long periods. Iām mostly concerned about the operations that happen often and for a long time. Hovering a stone or analysis tools are such use cases, at least for myself.
Out of the analysis tools, drawing freehand stands out - it creates a large number of paths with the short segments and is resource-intensive. Iām afraid that it has little low-hanging fruit here, though. In theory, the number of points could be reduced, for example with simplify-js, and then they could be fitted into a Bezier curve on the path.
Edit: the current pen tool is made with many path elements, each one a segment. Essentially, this is equivalent to a polyline. But likely it is more expensive because itās got a larger DOM and the algorithm to draw the paths is more complex (I havenāt tested this assumption). A second paragraph from the Mozilla docs says that polylines donāt scale well.
2 Likes
FYI Iāve updated the SVG renderer to re-use the canvas rendered stones so we can have a smooth transition to the new rendering system and so folks can keep the canvas stone aesthetics if they want.
Weāll still have the pure SVG stone variants (or at least some/most of them) for those that want them as we get closer to launch, but I wanted to test out the canvas rendered variants with yāall to help catch any bugs that may or may not exist with how that works.
5 Likes