The library Gadfly is written purely in Julia.
I would like to know how using pure Julia someone can plot graphics such as a line or a point. The source code is extensive and I could not find the source code for the plot command explained here. and I doubt it is simple enough to show how such a task can be done.
Can somebody provide me with a minimal Julia code that can plot a line? or Can somebody outline how using Julia it is possible to plot a line? Having a superficial look at Julia documentation I do not see how this can be done. Can somebody point where in the standard library such functionality is provided?
Have you seen the Gadfly.jl tutorial? That’s a good place to start.
I do not want to know how using Gadfly I can plot a line. From a programming point of view I want to know how Gadfly using pure Julia can plot a line. I do not have a background in computer science and I am just curious to know what tools Julia provides that allows someone to make a plotting library such as Gadfly.
As far as I understand (this thread has a long discussion about it), all the julia plotting packages apart from UnicodePlots.jl call deep down a library in another language. Gadfly calls Cairo, Plots with the default backend calls GR which is written in C, and each of Makie’s backends calls their own library, Cairo for Cairo Makie, OpenGL for GLMakie and WebGL for WGLMakie. So in that sense even Gadfly is not written in pure julia and the “drawing” functions are in another library.
If that is acceptable for you maybe Cairo.jl has some of the most transparent examples: Cairo.jl/Samples.md at master · JuliaGraphics/Cairo.jl · GitHub
Also take a look at Luxor.jl, which uses Cairo.jl under the hood, but it has a API more “julian”, which makes more easier to draw vector graphics in julia than work with Cairo directly.
I’d add to that, that WebGL and OpenGL are more considered a driver for the GPU than an actual drawing library like Cairo or GR.
So, that’s the most low-level you can go in that regard, if you want GPU acceleration.
I prototyped a pure Julia rasterizer at some point, which then would do the same as OpenGL, just on the CPU in 100% julia code. It turned out surprisingly short and actually still lurks in the Makie repository, waiting to get brought back to life:
I tried at some point to make it work with the newest Julia, so I think it runs right now, but if I remember correctly there was a bug that I didn’t have patience to fix.
I thought Gadfly outputs SVG, via Compose. It used to.
So, this is a little known project, but I find it immensely fascinating as it reinventing within Julia a drawing package from the ground up: GitHub - Sid-Bhatia-0/SimpleDraw.jl: Simple drawing package written in Julia
It is created by @Siddharth_Bhatia (I think that is their name) and I was shown their work some time ago. I think it is very exciting that such a proof of concept exists within Julia and although it is more of a proof of concept, it shows not only is making a drawing package native to Julia possible, it is being done.
This could well be the case. My whole knowledge of the topic comes from the topic I linked
On Github it was written that Gadfly is written 100% in Julia which made me think it does not call any external library.
From the documentation:
The primary backend is a native SVG generator (almost native: it uses pango to precompute text extents), though there is also a Cairo backend for PDF and PNG.
So strictly speaking it might not be 100% pure Julia, but I think this is a fairly academic point.
So far I understood that packages written in Julia such as Gadfly or Makie make calls to other external libraries which are written in another language for example C or C++.
As far as I looked on the Internet C or C++ does not have any functionality to plot a line on a monitor yet there are libraries written in these languages that can do that. As someone with no computer science background it is a bit puzzling for me! I looked further and this is what I understood so far:
Back in the days such as the MS-DOS era, someone could use C to directly plot something on monitor. But nowadays with modern C or C++ it is not possible to do so directly and instead these languages have to ask the operating system’s API for plotting functionality and this API or OS is itself written in C or C++. Now it looks like the OS uses a version of C that allowed it to develop plotting functionality while the version of C that people use these day has lost that functionality or at least the OS does not allow it anymore.
Can somebody let me know if what I just described is correct? In general I am puzzled how C or C++ does not have facilities for plotting yet other libraries can be written in these languages to do so. I encountered the concept of compiler bootstrapping. Is the same thing going on here for plotting?
Thanks for sharing this @TheCedarPrince . Yes, it’s me
@Reza-Reza Roughly speaking, if you are looking for an algorithm to draw a line 2D grid, then you can find it here: Bresenham's line algorithm - Wikipedia (see last code section). You can implement this in any programming language for a 2D grid, which is like an abstraction of your digital screen/monitor. If you want a Julia implementation of that algorithm, you can find it at SimpleDraw.jl/line.jl at 8ecdf9bde31200b3a559a1ee4052c59d7833c012 · Sid-Bhatia-0/SimpleDraw.jl · GitHub. Now to actually transfer data from this 2D array to your screen and get colors displayed so that a line is visible on your monitor, you’ll probably need some functions that give you that ability. Such functions are present in windowing libraries. One example is glfw (https://www.glfw.org/), which is written in C and is also cross-platform, so that you don’t have to write completely different code to display your 2D array on different operating systems.
And going a little further, the windowing libraries will eventually call through the OS to the graphics hardware driver. The driver code controls the hardware so that the appropriate signals are sent to the monitor for you to see the line. In OP’s old DOS days, the OS was essentially single-process and the running process had much freer reign to access the hardware directly. Now OS’s must coordinate access to hardware to prevent corruption.
And FWIW, most windowing libraries, OS’s, and drivers are written in C/C++.