QCustomPlot Discussion and Comments

Request to make QCPColorMap (and Data) to use more virtual functionsReturn to overview

As discussed in a few threads, there is a need to create live spectrograms (waterfall plots) using QCPColorMap. Ideally, one would be able to inherit from QCPColorMap (and/or QCPColorMapData) and re-implement some features to do allow for these cases where one row of data is being added at a time, rather than the entire data set. While it's definitely possible to modify the source code and modify these classes directly, I suspect there are users who would be more comfortable (including licensing points on modified source code) in just deriving and overriding.

At the very least, QCPColorMapData needs a virtual destructor. This would allow someone to inherit polymorphically, add in additional functionality that manipulates the data array to add in just one row, and then use this derived class in a class derived from QCPColorMap. Trying to keep as absolutely close to source as possible, what blocks me is that my class inherited from ColorMap doesn't have the friendship access to QCPColorMapData, so can't modify its buffer directly, but since I can't dynamic_cast to a derived (from MapData) class, I can't add in the functionality there either.

But more broadly, in the re-implementation I've done for my project, I think there could be a lot to gained by allowing non-trivial functions to be virtual. For instance, rather than using a C-Style array for the buffer, I've found using the C++ container classes to be a good design for my needs (consider Queue type classes for these kind of waterfall plots, eg). Obviously other groups have different needs, but giving virtual functions gives us the capacity to find the better solution that fits the need.

Hi Alex, thanks for the feedback!
I will consider your suggestions (the virtual dtor of QCPColorMapData should be no problem), and especially making QCPColorMap capable of taking in successive rows/columns.
The reason why it internally works with arrays and low-level operations like memcpy is due to memory efficiency and performance. Two-dimensional data maps become very large very fast, and they must be converted to color-coded image data (via scanlines) with high performance. This is much harder to achieve (if at all) with high level containers like QQueue (which is a contiguous array of stack pointers to non-contiguous, fragmented memory). You gain little but risk cache misses and branch-misprediction due to the memory layout of the rows/columns.