Add linegraphs

[dankamongmen]

NCPlot's histograms are good. We ought now add linegraphs. The fundamental difference is that linegraphs are a three-dimensional record, allowing multiple distinct sample sets (each mapped to a different (range of) color(s), natch).

[dankamongmen]

#1382 will certainly help with this

[MasFlam]

I don't think line graphs would be really possible without pixel/sixel, since blitting a straight line onto blocks or box drawing characters would probably be pretty unreadable for some angles. But on pixels there's no problem, all that's needed is some function for blitting pixel lines.

That means some functions for drawing basic shapes are probably desired in the API. Antialiasing exists too... Although AA might be better off done by the end user, with something like cairo.

[dankamongmen]

I don't think line graphs would be really possible without pixel/sixel, since blitting a straight line onto blocks or box drawing characters would probably be pretty unreadable for some angles. But on pixels there's no problem, all that's needed is some function for blitting pixel lines.

yep, i'd reached this same conclusion.

That means some functions for drawing basic shapes are probably desired in the API. Antialiasing exists too... Although AA might be better off done by the end user, with something like cairo.

i'd really, really like to find a good library for this and use it, something that works directly on RGBA buffers. i'm not experienced enough with graphics APIs to know what people want here, really (and don't care to write a bunch of code that in the end has nothing to do with terminals).

[MasFlam]

i'd really, really like to find a good library for this and use it, something that works directly on RGBA buffers.

Cairo has multiple output targets, including in-memory buffers. But from what I've seen it's not hard to draw simple shapes with it. It has plenty of other outputs though, so it would be a big dependency. But then anyone with GTK installed already has it...

[dankamongmen]

Cairo has multiple output targets, including in-memory buffers. But from what I've seen it's not hard to draw simple shapes with it. It has plenty of other outputs though, so it would be a big dependency. But then anyone with GTK installed already has it...

yep, i wrote some exploratory code along these lines last year, enough to get pango rendering. i wouldn't be opposed to an optional dep on cairo, perhaps even its bitch sister pango.

[MasFlam]

Isn't pango for text rendering though?

[dankamongmen]

yeah, it sits atop cairo. it wouldn't be directly applicable to this.

[MasFlam]

Okay, so my week-long easter break has begun and I'll have a lot of time to spend on coding. The question regarding line graphs is whether we want the optional cairo dependency for them or not. I personally don't think drawing just lines warrants it.

If we were to aim for some public API for pixel drawing, then yeah probably, but such an API would be a pain in the ass and not worth it since cairo can draw to memory buffers and those can be fed to notcurses, so it'd be completely redundant and add bloat. I'd say that's a nono.

So I'll look into implementing line graphs by drawing lines myself in the coming days probably. :)

[dankamongmen]

Okay, so my week-long easter break has begun and I'll have a lot of time to spend on coding. The question regarding line graphs is whether we want the optional cairo dependency for them or not. I personally don't think drawing just lines warrants it.

this is exactly what i was going to say -- line graphs seem nothing more to me than "draw a column of pixels, with the right colors at the right places." the plot widget currently works a column at a time, since that's how samples are organized.

[dankamongmen]

So I'll look into implementing line graphs by drawing lines myself in the coming days probably. :)

cool! i was going to take a look at this over the weekend, but if you particularly want it, i can leave it for you.

the one worry here is that the bitmap stuff is still very much in flux (i've got a branch outstanding which changes almost all of it at a fundamental level), and i expect linegraphs to possibly drive more change there. that code's very delicate simply due to the (unstated) perf requirements from bitmap drawing in various terminals.

[MasFlam]

i was going to take a look at this over the weekend, but if you particularly want it, i can leave it for you.

I was also looking at #1282 but QR codes are surprisingly complex.

the one worry here is that the bitmap stuff is still very much in flux (i've got a branch outstanding which changes almost all of it at a fundamental level)

I'm currently going off what's in USAGE.md. Will it not be possible to manipulate pixels in ncvisuals and draw them using the pixel blitter? Or do you have a different way of implementing line graphs on your mind, that doesn't do it through the ncvisual API?

[MasFlam]

I can't find a way to get info on how many pixels fit in a cell/ncplane. Is that a thing somewhere?

[dankamongmen]

I can't find a way to get info on how many pixels fit in a cell/ncplane. Is that a thing somewhere?

notcurses->tcache->cellpix{x,y}

[dankamongmen]

btw, these would ideally be just a multidimensional take on plot.c. which is unfortunate, because plot.c is completely unreadable, as it is faking generics in C. it might be easiest to use gcc -E to turn it into processed C and then fit your changes back in, idk. i definitely don't want this to be its own entire blitting system and all that, though.

i.e. we have ncplot. nclineplot would just be an ncplot with n vectors of samples. sorry for not explaining this before.

[MasFlam]

Yeah, plot.c is a mess, but you can see what I did on my fork on branch linegraphs – I basically include one file twice (really the same file recursively) with different macros. It's kind of poor man's generics, but it's better than having to end every line with \, and I think it's and okay way to do it

[joseluis]

notcurses->tcache->cellpix{x,y}

Could that information made available through the API? related: #1507