Without this correction the code would combine all lock regions according
to the minimum visibility range rules, and assign the combined area the
highest lock state within all items. This could produce quote long combined
lock regions, where apparently lock contention happened.
Combined lock regions should instead be split to show exactly where the
lock contention is present. Combining is still performed here, but only
within the minimum visibility range.
This new behavior was also present previously, but was mistakenly omitted
during code refactor.
Just display known running regions, keeping the unended ones infinitely
collapsed. This makes the CPU core usage graph possibly display wrong
data at the end of capture. Note that this behavior was also present in
previous releases.
We need to know if samples, context switches and messages are present to be
able to correctly calculate thread height. However, if the thread is not
visible, it is not necessary to provide a list of items to draw.
The prev == it condition could only fire on the first run of the loop,
and on all subsequent runs prev (=next-1) will never be "it" anymore.
Lack of this condition changes nothing, as the following lines checking
for time distance between next and prev satisfy the same exit condition
(i.e. next-1 will be "it" only if lower_bound does not find anything,
hence next is farther away than MinVisNs).
The folding process starts at the "next" item. The nextTime variable
represents a time point before which everything should be folded, because
all items in that range are smaller than MinVis range.
The lower_bound search finds a new "next" item, which will be beyond the
nextTime range. But nextTime has origin in the previous "next" item, which
may be not the last item in the folding range. If the distance between the
new "next" and the item before is smaller than MinVis, then the new "next"
item is also folded and the folding loop must continue to run.
