Edge linestyles not always working about graphmakie.jl HOT 5 CLOSED

Are you saying the slowdown is mostly due to the former, the latter, or both?

In mixed graphs (curvy and straight lines) probably both. In graphs without curvy lines where everything is just a line it is slow because of individual plot objects per edge.

I've updated #94 accordingly

from graphmakie.jl.

You think the proposed solutions are sufficient?

I don't like auto promoting to beziersegments because of performance reasons. I think it is a bit different for curvy edges, because there both options (beziersegments and linesegments) have a clear usecase. I figured in this case it would be better to just provide a better error message which tells the user to specify the plottype.

from graphmakie.jl.

I think that the specific graph being plotted should not influence whether this gets thrown for otherwise equal properties. More generally, that is probably the case for other vector-valued per-item properties too if there are any that Makie does not itself support. (?)

I'm not sure what makes the bezier case slow, is it the interpolation or is it the fact that every edge then has its own lines? Because if it's only the former, maybe the right solution would be to do Graphs.ne many lines plots instead of a single linesegments, and lift all properties in the same way that beziersegments uses? Or even to make beziersegments use zero interpolated points if the curvature is zero, subsuming the whole linearsegments case (and explicitly forcing zero curvature should it be required to straighten the lines), thus eliminating the distinction? Or am I missing something?

Otherwise if the performance issues come from using many lines, one per edge, I think that the better error message should get thrown if linestyle (or any property that Makie does not support per-item vector definitions for) is a Vector and edge_plottype is not :beziersegments. In the proposed solution, even with the better error, it is not obvious for somebody setting the linestyle vector that this issue might occur because they may not have tried with a graph that would trigger it.

from graphmakie.jl.

Or even to make beziersegments use zero interpolated points if the curvature is zero

Thats what happens in the moment. BezierPath <: AbstractPath can be an arbitrary path, that one gets discretized. If there is no curvature, the path for the edge is a Line <: AbstractPath with trivial discretization of just start end endpoint. In mixed graphs (some Lines some BezierPaths) this means the edge pathes array gets typeunstable with dynamic dispatch (at some point someone should investigate whether the type instability is worth the elided discretization). For just Lines it should be relatively fast. However if you plot graphs with a few thousand nodes it used to be quite slow, presumably because of all the individual plots. Thats why I don't want to give up the linesegments path which should be fine for most of the plotted graphs. Even though it would be much nicer to not have that distinction.

I am not aware of any other properties where this happens in the moment. So if I understand you correctly you'd prefer the combination of edge_plottype = automatic => becomes beziersegments to fail in combination with a vector of linestyles, forcing the user to always set edge_plottype explicitly? I'm fine with taht.

from graphmakie.jl.

In mixed graphs (some Lines some BezierPaths) this means the edge pathes array gets typeunstable with dynamic dispatch

it used to be quite slow, presumably because of all the individual plots

Are you saying the slowdown is mostly due to the former, the latter, or both?

So if I understand you correctly you'd prefer the combination of edge_plottype = automatic => becomes beziersegments to fail in combination with a vector of linestyles, forcing the user to always set edge_plottype explicitly?

Yes, I'd like any use of per-edge (vector) linestyle to fail with the new error unless edge_plottype = :beziersegments is set explicitly, to prevent the surprise of this error occurring inconsistently only for some graphs. (This would solve the issue for me.)

from graphmakie.jl.