| Re: [tracecompass-dev] What are the state history queries needed to display a view? |
|
Hi Michel, I think that there's a bit of an abstraction layer missing.
As code speaks, first thing we did was update the documentation for the code so it speaks more clearly.
Next up, I think you should look at the ITmfStatesystem interface, it is interfacing with queries, the backend is interfacing to the state system history front end.
>From a user perspective, this is the important API
<code>
Management:
getSSID()
getStartTime()
getCurrentEndTime()
isCancelled()
waitUntilBuilt()
waitUntilBuilt(long)
dispose()
Stuff to set up a query:
getNbAttributes()
getQuarkAbsolute(String...)
optQuarkAbsolute(String...)
getQuarkRelative(int, String...)
optQuarkRelative(int, String...)
getSubAttributes(int, boolean)
getSubAttributes(int, boolean, String)
getQuarks(String...)
getQuarks(int, String...)
getAttributeName(int)
getFullAttributePath(int)
getFullAttributePathArray(int)
getParentAttributeQuark(int)
Actual heavy lifting
queryOngoingState(int)
queryOngoing(int)
getOngoingStartTime(int)
queryFullState(long)
querySingleState(long, int)
query2D(Collection<Integer>, Collection<Long>)
query2D(Collection<Integer>, long, long)
The backend has the history tree. It is written in a bit more of a c-like way (passing arrays to be filled)
doQuery is a 1-1 map with query full state.
doQuery(List<ITmfStateInterval>, long)
doSingularQuery is a single quark single time query
doSingularQuery(long, int)
query2d will make a 2d grid
query2D(IntegerRangeCondition, TimeRangeCondition)
query2D(IntegerRangeCondition, TimeRangeCondition, boolean)
</code>
Our views typically use either 2d queries when possible (more efficient as no node is traversed twice) or single state queries for stuff like tooltips.
Please note, even if the 2d query is "theoretically" faster than a full stabbing state query (queryFullState), in tests, the full state query is sometimes faster. That is why you will see it here and there.
About view queries:
Sampling is done with:
resolution = (end-start) / width (a floored long)
Then we use StateSystemUtils.getTimes() which loops incrementing t += resolution.
So, if resolution is a bit shorted due to the floor, you'll get a little bit too many samples, so you could get two in the same pixel. And each sample can be anywhere in the pixel range.
Now we are also working on making a fixed raster pattern which should sidestep that problem and make the state aliasing pop be a problem of the past.
Hope this helps,
Matthew
From: tracecompass-dev <tracecompass-dev-bounces@xxxxxxxxxxx> on behalf of Michel Dagenais via tracecompass-dev <tracecompass-dev@xxxxxxxxxxx>
Sent: Wednesday, March 9, 2022 4:28 PM To: tracecompass-dev@xxxxxxxxxxx <tracecompass-dev@xxxxxxxxxxx> Cc: Michel Dagenais <michel.dagenais@xxxxxxxxxx> Subject: [tracecompass-dev] What are the state history queries needed to display a view? The state history backend interface offers three query methods: doQuery for the complete state at a time point, doSingularQuery for one state element at a time point, and query2D for specified state elements that intersect a specified time interval.
For most views, we need to display the state of specified state elements (e.g. state for each thread) for the time interval covered by the current zoom factor, and at the granularity of the pixel resolution of the screen within the view. Several strategies
are possible to draw each pixel column, in the row for the corresponding state element:
- doQuery at the time defined for the center of each pixel. We can color the pixel based on the state value for the state interval obtained at the pixel center. A variation would be to check the width of the state interval at the pixel center. If that
interval covers the whole pixel, or at least a large part of it, the color for that state value is used. Otherwise, a different color, possibly fainter, could be used.
- query2D (for the state elements to draw) for the interval covering a pixel. We may then get several intervals, with associated state values, for a state element for that pixel column (we are zoomed out and there are many state changes within a pixel).
If the state values are numerical, we could compute a weighted sum (each state value weighted by the length of the corresponding interval), or a min or a max value for the interval, to decide upon the color to choose to represent the state for that pixel.
The second strategy is obviously more precise but does not scale well. Indeed, for very large traces, the number of intervals for each pixel may become very large. The first strategy, on the other hand, scales well but could be considered a "sampling".
Nonetheless, because of scaling requirements, I assume that this is how Trace Compass works. Is that correct?
This question becomes very important for partial state history. To query the state at a specified time, you need to query the preceeding checkpoint and then read the trace until the specified time is reached. However, if we are looking at a huge trace,
with a zommed out view, there will be several checkpoints for each pixel. In that case, selecting the closest checkpoint to the pixel center, would give an acceptable value and would be much faster. Does that make sense?
For this to work, we need a way to communicate this information. Either the view queries the backend telling that the specified time is flexible within some interval, or the backend tells the view about where the checkpoints are.
|