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.
There are various changes involved into making this work:
1. Zone size (zsz) is no longer clamped to the timeline viewport area.
This clamping has to be removed to prevent otherwise uncollapsed zones
from apparently becoming small near the viewport borders. Such a small
zone would then be collapsed, resulting in unwanted popping.
Interesingly, only the CPU zones were clamped before. GPU zones were
not.
2. Iteration over visible zones has to start before the visible timeline
viewport area. Without this some zones that would be otherwise
included in the collapsed area (started by a previous zone) may be
fully visible. This causes child zones to be drawn and produces
unwanted popping. (At this point threshold for continuing collapsed
area is greater than threshold for starting it.)
3. Since the iteration now starts before timeline visible area, it may so
happen that everything found will be in a small slice of timeline that
is outside the screen. To fix this, the end time of last found item is
checked against the viewport start time.
It is always valid to access *(zitend-1), as it is in each case done
after null set check (it == zitend).
Similar but simpler fix was also applied to per-thread call stack samples.
Bartosz Taudul
Kirk Klobe