I've started implementing
some changes in how GtkDatabox handles input data, along the
lines of my earlier posting. Would like some feedback on the
interface, and on whether worthwhile or not. It can be done in
a completely backwards compatible way.
GOALS:
1. more flexible / robust data handling (handle non-float data,
growing arrays, ring buffers, matrices where the data is a
particular row or column).
2. be backwards compatible with existing scheme
3. minimize or eliminate data copying / memory allocations
PROPOSAL:
instead of passing a (gfloat *) pointer and a length:
pass a (void *) pointer, a starting offset, a stride number, and
the number (length) of samples to process, as well as the size
of the allocated buffer, which may be less than the length when
dealing with a ring buffer.
The idea is to treat the data as coming from a matrix of
floats/doubles/ints. If gtkdatabox is told to go beyond the
available number of rows of data, then wrap around to the
beginning (i.e. treat as ring buffer). In the simple case, the
matrix has one column of floats, in which case it's just like
what we have now.
API CHANGES
For complete backwards compatibility, keep the current
convenience allocators:
gtk_databox_lines_new(len, X, Y, color, size);
but add something like these:
gtk_databox_lines_new_full(allocatedlength, length,
X, xstart, xstride, G_TYPE_INT,
Y, ystart, ystride, G_TYPE_DOUBLE,
color, size);
gtk_databox_graph_data_update(graph, allocatedlength, length,
X, xstart, xstride, G_TYPE_INT,
Y, ystart, ystride, G_TYPE_DOUBLE);
where xstart/ystart are almost always 0, and xstride and ystride
are usually 1 (or at least equal to ncols if the data is in a
matrix).
WHAT FILES/FUNCTIONS WOULD CHANGE
1. gtkdatabox_xyc_graph.c and gtkdatabox_xyyc_graph.c
2. gtk_databox_value(s)_to_pixel*()
3. Also, each of the graphs' *_real_draw() functions need minor
changes.
FOR SIMPLE LINEAR ARRAYS:
Where for a linear array like our current ones:
X and Y are the starts of their arrays,
length and allocated length are usually the same,
xstart/ystart are 0
xstride/ystride are 1
Note if you want to plot only a subset of the array, can alter
xstart/length, no need to reallocate, or memory copy.
FOR MATRIX DATA:
But if the data comes from a matrix with, say 2 columns, 10
rows:
A00 A01
A10 A11
A20 A21
A30 A31
..
A90 A91
and we want the plot the first column as X, the second as Y:
Then X could point to A00, Y could point to A01
xstart is 0, ystart is 0, since we want to start with the first
row.
xstride and ystride are 2 since there are two columns
and length and allocated length are 9, since X will have a
maximum of 10 elements, and we want to plot all 10 elements.
FOR REAL TIME DATA:
Most people use ring-buffers for data collection here. With the
proposed data handling, it should be easy to scroll data. No
memory copies.
A0 A1 A2 A3 A4 A5 ... A9
if we are plotting 5 elements, and the newest data in the ring
buffer was on A2 (and it's wrapped around already), then pass it
the following:
X = A0
xstart = A2-5 = A8
length = 5
allocated length = 10 (it will know to wrap around to the
beginning because xstart + length is past the allocated length.
xstride = 1
ALTERNATIVES:
GArrays have been proposed as an alternative. Problems wtih
GArrays:
1. It's hard to implement in a backwards compatible manner.
2. Most users of gtkdatabox, I'd guess, are not doing their data
analysis using glib structures like GArrays. So if your data is
already in some format in memory, you'd have to copy it into a
GArray for GtkDatabox
3. Also, there's nothing magical about GArray. All it does (I
assume) is internally call realloc() if adding an element
increases things beyond the allocated storage. That's just not
hard to do with the existing float arrays method.
But I don't want to waste a lot of time. I have no real need
for this myself. I can get rid of the xstart/xstride/etc, and
leave the type field, and add support for
G_TYPE_FLOAT/G_TYPE_DOUBLE/G_TYPE_INT. That's rather easier.
If the consensus is this is all too complicated, I'll stop.
Sincerely,
--
Amish
_______________________________________________
gtkdatabox-list mailing list
gtkdatabox-list gnome org
https://mail.gnome.org/mailman/listinfo/gtkdatabox-list
