Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 352885

Summary:

[LTTng] Refactor the Histogram View

Product:

z_Archived

Reporter:

Francois Chouinard <fchouinard>

Component:

LinuxTools

Assignee:

Francois Chouinard <fchouinard>

Status:

CLOSED FIXED

QA Contact:

Francois Chouinard <fchouinard>

Severity:

normal

Priority:

CC:

overholt

Version:

unspecified

Target Milestone:

---

Hardware:

OS:

Linux

Whiteboard:

Bug Depends on:

Bug Blocks:

321364

Attachments:

Description	Flags
Refactoring of the Histogram View	fchouinard: iplog-

Description Francois Chouinard

2011-07-22 11:46:48 EDT

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.

Comment 1 Francois Chouinard

2011-07-22 11:53:33 EDT

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.

Comment 2 Francois Chouinard

2011-07-22 18:54:53 EDT

The remaining work is moved to Bug352922.

Comment 3 Francois Chouinard

2011-08-09 20:07:24 EDT

Comment on attachment 200211 [details]
Refactoring of the Histogram View

Patch was committed

Comment 4 Andrew Overholt

2011-08-15 14:35:39 EDT

Is this suitable for a bug-fix release (0.8.1) or should the Target Milestone be set to 0.9.0?

Comment 5 Francois Chouinard

2012-03-26 13:57:20 EDT

Delivered in 0.9.0