Community
Participate
Working Groups
The current Histogram scheme can not practically be used for trace streaming due to the following shortcomings: [1] The histogram requires knowledge of the full experiment/trace time range before drawing - This works for non-streamed LTTng traces because the traces hold the end time info in the metadata (although this is certainly not the general case i.e it doesn't apply to most other trace types) - For streaming, the scheme simply falls apart: we have to rebuild the entire histogram every time there is an update - Rebuilding the entire histogram means that we have re-read the entire trace - As the traces grow larger, every update will takes increasingly more time [2] Data model tightly coupled with the UI widget - The histogram buckets ranges are pre-computed given the trace range and the number of pixels allocated to the histogram - The histogram model (the buckets) is tied to the UI widget itself - Resizing the histogram throws off everything and triggers a complex re-mapping that fails in many if not most cases. Only an expensive full re-read of the trace can then give a satisfactory result. [3] The histogram drawing buckets boundaries have floating point values - Every incoming event timestamp requires a floting point comparison to know in which bucket it falls - This is not really a shortcoming, just an inefficiency Notwithstanding the streaming issues, it would also be nice to add the following features: - Selection of the current event directly in the canvas (histogram) - Zooming directly in teh histogram (not only in the range window on the full histogram) Finally, this view is not really tied to LTTng traces and there is not good reason not no make it generic thus re-usable by any tracing application based on TMF.
Created attachment 200211 [details] Refactoring of the Histogram View This patch is essentially a full refactoring of the Histogram view. It has the following features: [1] (almost) Generic histogram data model that de-couples the data from the UI. It handles the event counts and their mapping to a given canvas. [2] Generic histogram widget that can be re-used easily by any TMF view. It handles dynamically the canvas, its x-/y-axis and the current event selection [3] An histogram zoom which handles the resizing of the active time range [4] A time range histogram which handles its re-sizing [5] A full trace histogram which handles the move and re-sizing of the time range window Also, most of the earlier code was either refactored or simply removed. There is very little work left to make the view completely generic. I intend to complete it shortly.
The remaining work is moved to Bug352922.
Comment on attachment 200211 [details] Refactoring of the Histogram View Patch was committed
Is this suitable for a bug-fix release (0.8.1) or should the Target Milestone be set to 0.9.0?
Delivered in 0.9.0
