Removing deprecated and broken backends

[oschulz]

While trying to reduce the load time of Plots, I realized there may be a chance to also reduce the time spent in code-gen. Not sure, but I'd like to try. However, it would be much easier without lots of broken and deprecated backends.

Maybe it's time to rip out all of those defunct/deprecated backends right now? Which backends should we keep?

[mkborregaard]

I essentially did that under vizcon: https://github.com/JuliaPlots/Plots.jl/pull/1818/files
The remaining backends, gr, pyplot, plotly(js) and pgfplots all have regular users associated with them.
The only questionable one is inspectdr - not sure whether that's in widespread use. Do you think it would add anything to rip that out?

HDF5 is not really a backend - it's an implementation of the HDF5 save format for Plots that is implemented as a backend for clarity.

[oschulz]

Ah, right - great!

What about plotly(js) though - I heard they were broken, currently?

I agree regarding HDF5, I thought about that myself while I overhauled the package init. It should be represented as an output format (and so far the only input format) for plots, now matter what backend they were generated with, instead of being a backend itself.

@ma-laforge , I think you implemented most of it, what do you think, regarding HDF5?

[mkborregaard]

I believe PlotlyJS is fixed now

[oschulz]

I believe PlotlyJS is fixed now

Great!

So the only question is indeed whether to keep inspectdr - does anyone know what it's status is (@ma-laforge maybe)?

[mkborregaard]

Wow, there's an important one missing from our links - UnicodePlots! @Evizero is that working for 1.0? I get some errors when I try it.

[oschulz]

Oh, yes - UnicodePlots will definitely stay, of course!

[Evizero]

UnicodePlots should work in 1.0 without issues. I am guessing you mean the Plots backend? I know nothing about that. That said I am in the process of upgrading UnicodePlots a bit (finally writing proper tests and such). Once that is done and merged I will look at the Plots backend code a bit and see what I can do.

[mkborregaard]

Great!

[ma-laforge]

@oschulz: [...] It should be represented as an output format (and so far the only input format) for plots, now matter what backend they were generated with, instead of being a backend itself.

I created HDF5-Plots as a backend simply because it was the simplest way for me to hook into the module. The Plots.jl is quite complex, and I did not want to break anything, however...

• One advantage of having HDF5 as a backend, however, is that people that don't necessarily want to display the plot at the time of creation do not have to pick (or install) a graphical backend.
• The HDF5 plot backend "supports" all features. What I mean here is that it can (in theory) natively save all plots without first having to convert certain aspects to a polyline, for example.

I also did it that way because, by making HDF5-plots into a backend, I figured the idea was less likely to be rejected since the backend does not have tenticles all over the code base :).

That being said, I am not particularly attached to the way HDF5-plots was implemented.

Why are the base plot objects tied to a backend??

That is my question.

I see the need to have an object tied to a backend only for display purposes (ie so that the right backend gets called when you display(plot)), but I am not sure why the base object has to be specialized withthe backend. Could we not have done something like:

struct Plot{BACKEND} #Wrapper object to dispatch display function
   p::BAPlot #Backend-agnostic plot object
end

?

If we had truly backend-agnostic plot objects (where all properties were stored natively), then there would be no reason for HDF5-plots to be masquerading as a backend.

[ma-laforge]

@oschulz: So the only question is indeed whether to keep inspectdr - does anyone know what it's status is (@ma-laforge maybe)?

• The InspectDR backend is working in Plots.jl at the moment.
• Is the userbase large enough to warrant the Plots.jl team not to remove it from the supported backends? I am not certain I am the one to answer this question.

However, the comments I have received indicate that those who use InspectDR either like:

• The interactivity it provides (mouse-driven pan, zoom, etc).
• The speed at which it can plot larger datasets (>200k points).

As far as I can see it appears the other backends do not have the same level of speed/interactivity yet.

[mkborregaard]

I also think we should keep inspect-dr, @ma-laforge is very responsive to issues and it is almost 0 maintenance for us, and it does have a userbase.

Also, yes, it would be possible (and a good idea) to have backend-free plot objects, and in fact that was a vision of Tom Breloff's. It was discussed most recently as a year ago #390

[oschulz]

If we had truly backend-agnostic plot objects (where all properties were stored natively), then there would be no reason for HDF5-plots to be masquerading as a backend.

Yes, I've bee thinking about that - I want to look into a few things to reduce time to first plot, and was looking into possible structural changes. I have a feeling that the Plot struct doesn't need to be parameterized by backend type. Then one could simply plot with a no-op backend, save the plot to HDF5, load it in another session and then show it with any backend.

[oschulz]

I also think we should keep inspect-dr

Sure, if it's working and actively maintained, then definitely.