Remove Base.Graphics from Base and make it a package

[dhoegh]

By looking at @timholy coverage results, I saw that Base.graphics is virtually untested. The module seems to be self-sustained, it does not seem to be used in Base or requiring any low level code implementation in Base. Therefore I think it is natural to implement it in a package in order to reduce Base according to #5155. The module seems to be used in the Color.jl package.

If could be removed it would be good to get the deprecation process going in 0.4

[garborg]

Winston uses it. Wherever it goes, my main wish would for it to evolve into something both Winston and Compose use, instead of Compose needing to define its own version of BoundingBox and co., without sharing methods.

Then I'd like bounds, points, polygons, etc., in geospatial packages to be able to inherit / delegate methods and draw to either backend for free. Maybe moving it out into a package would mean more freedom to iterate on design until it was more useful?

[timholy]

Relevant: #9814

I think it exists in the hopes that it will encourage some degree of sharing among various packages dealing with graphics. In addition to Color.jl, it's used at least in Cairo.jl, Gtk.jl, Images.jl, ImageView.jl, ProfileView.jl, Tk.jl, and Winston.jl. But it hasn't been used in quite a few other packages, like Compose.jl or (AFAICT) any of the OpenGL stuff.

[dcjones]

It's not just a matter of refactoring Compose to use Base.Graphics. Nothing in Base.Graphics is remotely compatible with Compose. The issue is that Base.Graphics defines a imperative graphics API (like Cairo) whereas compose is thoroughly declarative (like SVG). Though it would be possible to write a compatibility layer to coerce compose graphics out of this api, it wouldn't be fun to implement nor greatly benefit anyone.

If we were to share graphics code, maybe a more fruitful direction would be to do so at the level of geometry: define types and functions in Base for polygons, rectangles, lines, curves, computing bounding boxes over geometry, etc.

[garborg]

Sorry, I guess I maybe I underestimated the difficulty of an upstream package's points, lines, polygons, boundingboxes, being usable by either approach, in spite of the divergence of approaches. My 'for free' wording was a little stronger than I was actually envisioning, but your suggestion about some geometric types in Base, along with whatever methods on them are basic enough to be useful across approaches, is what I was thinking.

[JeffBezanson]

The intent of Base.Graphics was to capture whatever is useful to share among graphics packages. So, anything that's not useful in that way should be removed. Based on the current state of things, it looks like it would make sense to create an external Geometry.jl package and remove Base.Graphics.

[ViralBShah]

I have been thinking about this too, and an external package seems like the way to go.

[tknopp]

+1 Yes it is always good to agree on common infrastructure. But this should evolve in packages.

It is always very hard to define an interface before knowing the exact requirements. And the big advantage when this evolves in packages is that one has more flexibility to try things out an experiment with ideas. Further this is driven by existing code (in Winston and Compose). So its likely that whatever the result is that it useful.

[lobingera]

I like the idea to centralize (2D)-geometry related functions and data types into a dedicated package.
point types, line types, polygons, splines (b- and other)
and an extensive library for converting (e.g. complex value to a 2D point).
And i think this could stay in Base - so we limit the propability someone reinvents this in her/his package.

Everything above that (point to line relations, inside-outside testing etc.) is already a matter of computational geometry and this a dangerous numercal field, so i'd rather see library calls there, then local julia code.

GCAL, lib2geom etc.

[IainNZ]

+100 to removing it into a package, its just lost inside Base and isn't a fully formed idea yet. It can always come back in the future (but I don't think it needs to).

[ViralBShah]

#9814 should be included in the new package when this is done.

[dhoegh]

Should this be closed due to #10150

[ivarne]

Yes, I think so.