[tracecompass-dev] Fw: Using StateItem and interval colors to present mu

["David Wootton" <dwootton@xxxxxxxxxx>]

I just realized I didn't attach the patch, so here it is.

Dave
(See attached file: CallStackDataProvider.patch)
----- Forwarded by David Wootton/Poughkeepsie/Contr/IBM on 02/26/2019 06:50 AM -----

From: David Wootton/Poughkeepsie/Contr/IBM
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Date: 02/25/2019 04:00 PM
Subject: Re: [tracecompass-dev] Using StateItem and interval colors to present multiple views of same trace

---

I have been looking at this problem off and on for the last couple months as time permits, and I don't think it's solvable with the Trace Compass 4.3 release.

I started with Bernd's suggestion to have my data provider class, which extends CallStackDataProvider, handle filtering subsets of time events based on my type classification (barrier, lock, or something else) of .events. It seemed that the way to solve this was to override CallStackDataProvider's getRowModel method, and in my implementation, first calling CallStackDataProvider.getRowModel() to build the data, then post-process the resulting data to remove events I didn't want to display.

That didn't work since I needed access to the state system and the quark the events were built from, along with the result of getRowModel, and I didn't see any way to get the quark I needed that. I needed access to the quark in order to build a path to get a second quark I maintain in parallel with the one used by the CallStackView model.

My next attempt was to make my old Trace Compass 3.1 version code work with the current Trace Compass code, but I think too much has changed to make that practical.

I finally decided that the way to solve this was to modify the behavior of CallStackDataProvider.getRowModel() to decide itself to keep the event or discard it. Unfortunately, that means I need to copy, not extend, the getRowModel method, and since that method depends on other fields and methods in CallStackDataProvider that are marked private, resolve the access to them by changing them to be protected instead of private.

The attached patch shows what I had in mind.

I'd prefer not to copy getRowModel in its entirety, and think  hook, as noted by my block comment in getRowModel would solve the problem. I don't know if this results in an unacceptable performance slowdown by my building the path to my second quark and then to query that quark at a specific instant in time for each event processed  by getRowModel.

I spent a couple days last week trying to get a working Maven build of Trace Compass code with this patch, but I'm doing something wrong so that failed and I can't afford to spend any more time on that.

Is my third approach anywhere near reasonable? Does implementing the hook I suggest make sense and not kill performance?

For planning purposes, we are restricted regarding which Eclipse and Trace Compass releases we can use, where our next opportunity after the 2019-03 release is the 2020-03 release.

Dave

Bernd Hufmann ---01/07/2019 04:20:02 PM---Hi David Looking closer at the source code, using IFilterProperty.EXCLUDE (and IFilterProperty.DIMME

From:        Bernd Hufmann <bernd.hufmann@xxxxxxxxxxxx>
To:        tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Date:        01/07/2019 04:20 PM
Subject:        Re: [tracecompass-dev] Using StateItem and interval        colors        to        present        multiple views of same trace
Sent by:        tracecompass-dev-bounces@xxxxxxxxxxx

---

Hi David
 
Looking closer at the source code, using IFilterProperty.EXCLUDE (and IFilterProperty.DIMMED for some extend) will only work together with the filter feature. The filter dialog needs to be active. Sorry, for leading you in this direction.
 
After re-reading your original post, I think the reason why certain items are disappear when zooming out due to the fact that the state system is queried at given times. The times to be queried depends on the number of pixels and the start and end time of the current zoom window range. So, while zooming in and out it could happen that for a given pixel, different state is “hit” in the state system. That could explain why things randomly disappear. 
 
Not sure what to suggest next. Maybe looking into having different data providers for the different views of your data. Each data provider would only return the relevant data. You could override getProviderId() of the FlameChartView and provide the ID of the data provider corresponding to the current view of the data. This would be similar what you had initially with different state systems. 
 
Please let me know how it goes.
 
Thanks
Bernd
 
From: tracecompass-dev-bounces@xxxxxxxxxxx <tracecompass-dev-bounces@xxxxxxxxxxx> On Behalf Of David Wootton
Sent: January-07-19 9:36 AM
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Subject: Re: [tracecompass-dev] Using StateItem and interval colors to present multiple views of same trace

Bernd
This sort of works.

I started by trying to call timeEvent.setProperty in GetStateTableIndex in my class extending CallStackPresentationProvider and returning the index for my default color since I had to return something. That didn't work.

Looking at Trace Compass code it looked like I could do this by overriding BaseDataProviderTimeGraphView.createTimeEvents. I implemented a method that first calls the superclass createTimeEvents method then iterates over the list that method returns, setting the IFilterProperty.EXCLUDE property as needed.

That didn't work either. Then I tried setting the IFilterProperty.DIMMED property instead and that works, where the events changed to a dimmed state.

I'm not sure why the IFilterProperty.EXCLUDE property isn't working.

Any ideas?

Dave

Bernd Hufmann ---01/04/2019 02:11:56 PM---Hi David When implementing the dynamic filtering of time graph views (activated by keystroke /), we

From: Bernd Hufmann <bernd.hufmann@xxxxxxxxxxxx>
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Date: 01/04/2019 02:11 PM
Subject: Re: [tracecompass-dev] Using StateItem and interval colors to present multiple views of same trace
Sent by: tracecompass-dev-bounces@xxxxxxxxxxx

---

Hi David

When implementing the dynamic filtering of time graph views (activated by keystroke /), we added properties where we can hide or dim time events (intervals as you call it). I’m wondering if you could try to use the property IFilterProperty.EXCLUDE to achieve your goal. So, to hide time events, just do “timeEvent.setProperty(IFilterProperty.EXCLUDE, true)”. This will hide the time event and if the whole row becomes empty it will remove the whole row. Do this instead of the StateItem way that you implemented.

Please let me know how it goes.

Best Regards
Bernd

From: tracecompass-dev-bounces@xxxxxxxxxxx <tracecompass-dev-bounces@xxxxxxxxxxx> On Behalf Of David Wootton
Sent: January-03-19 4:35 PM
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Subject: [tracecompass-dev] Using StateItem and interval colors to present multiple views of same trace

When I updated my plugin to work with Trace Compass 4.1 it occurred to me that I could reduce storage utilization and improve performance for one type of my traces.

For one type of trace, the primary trace view displays all of the intervals in the trace. I have two secondary traces that display subsets of the intervals in that trace.

Originally, I implemented this by implementing individual analysis modules and state systems for each of the trace views, then switching between those state systems.

In my Trace Compass 4.1 changes, I thought I could manage this by using StateItem objects, including the StateItem table index INVISIBLE, which I used to hide an interval in my subset views. I accomplished this by keeping a separate map of event names and an event class that interval represented. My subset trace views then returned INVISIBLE for intervals which did not match the event class for my subset trace view.

I originally thought this worked, but after working with it more, I think I have made bad assumptions and that this will not work

The problem I have is that the display behaves erratically, where I have not been able to identify a pattern. If I switch from my main view to a subset view, that seems to work correctly If I switch between subset views or zoom in and out, then intervals randomly disappear, maybe because my code is incorrectly setting StateItem index to INVISIBLE.

If I select an interval from the trace table view, then that interval appears in the trace view.

I think part of this may be du to intervals which contain multtiple intervals within them, because I'm zoomed out far enough that a single pixel represents a duration spanning multiple intervals. I'm seeing the tooltip text for these intervals displaying 'MULTIPLE' instead of an event name.

The other thing I'm seeing is that if I hover the mouse over the space where an interval marked as INVISIBLE exists, then I get tooltip text for that interval, meaning it's in the view, but I just can't see it.

Have I made some bad assumptions and done something I shouldn't have?
Dave_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/tracecompass-dev

_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/tracecompass-dev

Attachment: CallStackDataProvider.patch
Description: Binary data