Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tracecompass-dev] Using StateItem and interval colors to present multiple views of same trace

Bernd
I'm looking at the approach you selected and am a little confused.

The data provider class I'm extending is org.eclipse.tracecompass.internal.analysis.profiling.core.callstack.provider.CallStackDataProvider. There's a second CallStackDataProvir class in Trace Compass source at org.eclipse.tracecompass.internal.tmf.core.callstack/provider but that's marked deprecates, so I'm assuming that's the old one I shouldn't use.

I don't see any fetchRowModel() method. I'm assuming you mean getRowModel().

The getRowModel method is passed a SelectionTimeQueryFilter that looks like it is passed a list of IDs and a time range. I don't see how I add a Predicate.

I did override the addToStateList method to add a simple predicate to the map of Predicates it's passed and had the test() method return true for one test and false for a second test. In the case it returned true, it looked like the trace was identical to how the trace looked without this code added. If the test method returned false then the events in the trace appeared dimmed. That may be because I'm not doing anything with properties and I'm just getting some default behavior.

However, I had attempted something along these lines last month with IFilterProperty.EXCLUDE and IFilterProperty.DIMMED, then you realized that this only worked if I had a filter dialog active and where I apparently don't have one active.

If I'm encountering this again, then it looks like this approach doesn't work.

If this proposed solution avoids the filter dialog requirement, then I probably don't have the correct logic for the Predicate and this looks encouraging since I think I can get access to the state system and quark at this point.

Thanks

Dave


Inactive hide details for Bernd Hufmann ---02/28/2019 09:57:25 AM---Hi David >> Is my third approach anywhere near reasonable? Bernd Hufmann ---02/28/2019 09:57:25 AM---Hi David >> Is my third approach anywhere near reasonable? Does implementing the hook I suggest make

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





Hi David

>> Is my third approach anywhere near reasonable? Does implementing the hook I suggest make sense and not kill performance?
Having a hook sounds a reasonable approach, since you don’t need to update/copy several other methods.


Alternatively, I’m wondering if you could leverage the TimeGraphStateQueryFilter that can be passed to the fetchRowModel(). You would then override fetchRowModel(), create a new TimeGraphStateQueryFilter from the passed filter instance that adds a predicate for your filter purpose, call the super.fetchRowModel() with the new filter. On top of this you would have to override method addToStateList(), add your logic for filtering and call super.addToStateList() to be able to use the filter dialog as well. A little disclaimer, I haven’t tried this just browsing the code, but looks promising.

>> Does implementing the hook I suggest make sense and not kill performance?
About the performance, doing a state system query for each time event for sure has performance impact. The worst case is, when zoomed out totally, a query per number of pixels for each row. My suggestion above will have the same impact than your “hook”-solution.

>> 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.
From your previous posts on the mailing list I understood that you are building with Maven on Windows. There are problems right now building with Maven on Windows. It’s mainly due to UI tests using SWTBot. The windowing system on Windows sometimes behaves differently than on Linux and there are failures of test, but in reality, they are not errors in the software itself. Due to lack of resources we only support the Windows build with best effort. So, I suggest to either build on Linux or disable the test execution in Maven or skip UI tests with -Dskip-automated-ui-tests.


>> 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
March 6, 2019 is RC1 build, which is feature and API freeze for the 2019-03 release. Only bugfixes can be merged before RC2 (last build for the release) the week after. So, if you need some change for 2019-03, please provide the patch early next week so we can get it merged by then.

BR,
Bernd

From: tracecompass-dev-bounces@xxxxxxxxxxx <tracecompass-dev-bounces@xxxxxxxxxxx> On Behalf Of David Wootton
Sent:
February-25-19 4:01 PM
To:
tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
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


Inactive hide details for Bernd Hufmann ---01/07/2019 04:20:02 PM---Hi David Looking closer at the source code, using IFilterPrBernd 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


Inactive hide details for Bernd Hufmann ---01/04/2019 02:11:56 PM---Hi David When implementing the dynamic filtering of time grBernd 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

_______________________________________________
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



Back to the top