...
for i in indices # loop over polygons
# get the list of vertices of this polygon
vlist = hcat(vertices_list(sol.Xk[i])...).'
@series (x, y) = vlist[:, 1], vlist[:, 2]
end
and the GR backend (it is sligtly faster than other backends such as PyPlot but still this is negligible since both take several minutes). This is all good, but I was wondering if this task can be accelerated by using an alternative setup.
Alright, i’ve installed GMT.jl and can reproduce the rectangles examples
Do you have an example for my use case? I tried plot!(vlist, region=R, show=false, fill="blue") written in a for loop (as above). The plots looks ok for N=1000 sets, but the problem is that it pops up a lot of windows, one after the other, so i can’t try higher instances. (FWIW, in Plots you would do something like my_plot = plot(...); plot!(my_plot, ...).) I expect to get one single graph with all the plots.
I also tried a single command plot(vi, region=R, fill="blue", show=false) where vi is the concatenation of all the polygons (vertically), and the plot looks strange. Is there a special argument to separate the different shapes? (like a NaN).
In any case thanks for the pointer to GMT, that I would like to explore further
Indeed, I remember that is a valid input from reading the docs, but didn’t take it seriously as a performance factor… yet it is For a N = 10000 instance I get a 30x speedup (!).
Ah, sorry you found a small bug. With this calls it’s not checking the value of the show keyword and it takes it always as true. So the solution meanwhile is to not use at all (when not needed). Here is an working example that creates a png image:
However, this would be terribly inefficient for 1000’s of polygons. So yes you can use NaNs.
julia> pp = [p1; NaN NaN; p2; NaN NaN; p3];
julia> plot(pp, region=[0 5 0 5], fill=:blue, fmt=:png, frame="a", show=true)
There is even a more versatile way where one can specify different line widths, fill colors etc by creating GMTDataset type an filling in the segment headers but will need to consult the code to see if I had already implemented the interface in GMT.jl that allows calling this feature of GMT (no the wrapper but the package itself).