Open markers

[jkrumbiegel]

Open markers are often recommended because they allow discriminating overlapping data points better than closed markers. Here I'm adding convenience functions that match :circle and :rect markers with adjustable inner radius. I've not really seen many other open markers in the wild but more could be added later. One can also use stroked markers for the same effect, but for example in AoG, one can then not use the default color mapping which is annoying when switching between markers.

data = RNG.randn(200, 2)
f = Figure()
scatter(f[1, 1], data, marker = open_circle())
scatter(f[1, 2], data, marker = open_circle(0.5))
scatter(f[2, 1], data, marker = open_square())
scatter(f[2, 2], data, marker = open_square(0.5))
f

[MakieBot]

Benchmark Results

SHA: 6a4ccdaf873da0e0cf78042fc8a818d55e5e79fc

Warning

These results are subject to substantial noise because GitHub's CI runs on shared machines that are not ideally suited for benchmarking.

[lazarusA]

could we also do ?

scatter(f[1, 1], data, marker = open_circle(), color=data, colormap=:plasma)

[jkrumbiegel]

@lazarusA sure why not :) or did you mean adding that as a test case? It's not different from any other markers

[lazarusA]

oh, nice! if it works we don't need a test 😄 !

[aplavin]

I've not really seen many other open markers in the wild but more could be added later.

I saw and used quite a few open markers – in addition to these two, remember 45 deg tilted square ◇, and triangles like ▷.
My workflow is generally open this page https://en.wikipedia.org/wiki/Geometric_Shapes_(Unicode_block) and look for the desired unicode symbol :) Works relatively smoothly in Makie, aside from size inconsistencies (#4831).

More explicit support (this PR) would be nice – gives more control on the "stroke" width.

[jkrumbiegel]

Ok I've added a bunch of other markers, all implemented in the scaled cutout way currently. This is not perfect because the "stroke width" differs a bit depending on the angle of the lines, but I'm not motivated right now to do a better one. We can still do that later and I would consider the slight changes of widths suitable for a patch release then.

[jkrumbiegel]

any idea why WGLMakie would fail here @SimonDanisch or @ffreyer?

[SimonDanisch]

Seems like a similar problem as in: #4879

Testing here:#4938
Of course it doesn't reproduce locally -.-

[ffreyer]

Isn't this what you mentioned in #4829 as not working well for general shapes?

Doesn't this approach mean that the strokewidth scales with markersize? I.e. if you wanted 2px strokewidth with N markersizes you'd need to produce N different markers? That sounds problematic with the finite amount of space in the texture atlas. Especially when strokewidth already exists. Maybe it would be better to do something like

if user_strokecolor === automatic
    backend_strokecolor = is_open_marker(user_marker) ? user_color : :black
else
    backend_strokecolor = user_strokecolor
end

after #4630?
If the roundness of stroke is a problem I'd imagine it could be improved by changing the sdf generation. Probably only to a point due to the limited size of the texture element though.

Another point - since all the other Bezier markers have a Symbol name associated with them, shouldn't these do too? I.e. :open_circle for the default, instead of, or rather in addition to a function call?

[jkrumbiegel]

Ah yeah nobody really reacted to that earlier issue with implementation ideas. But if you think a stroke version would be feasible, that might be an option, too. I mean both variants have their benefits, but a stroke is just easier to reason about as it's independent of markersize. On the other hand, the markers become slightly larger due to the stroke, in the current implementation the open markers are exactly as large as their closed counterparts.

About the symbols, yeah I thought about that, too. I didn't do it because of the parameter, but in an earlier draft I had a way to specify the fraction via the name. Like :open_circle_50 for 0.5