ui: Fix disappearing slices by removing an optimization that assumes sorted slices in BaseSliceTrack #3044
Conversation
Currently we make the assumption in BaseSliceTrack that slices are ordered by ts when rendering them, which allows us to cull slices that are outside of the viewport. However, there is no explicit order by guarantees in the track query, so this ordering is not a given, it just happens to be that most track sources are inherently ordered. This patch simply adds an `ORDER BY tsQ` clause to the query, forcing the results to be ordered by timetstamp. Change-Id: Ieb76f56fe893543701f9d73c5f41394b8f6baf69
- Remove optimization that relies on slices being sorted in the first place. Change-Id: I001737e4a200a9b14f235fd07e616e28f0a8c632
stevegolton
changed the title
This is definitely a bug in the base slice track renderer. I'm not quite sure why we don't see the problem more often, but apparently your trace is just unusual enough to provoke it. |
Right, I originally thought the data is out of order at the table level, but it's a UI issue. LGTM. |
Currently we make the assumption in BaseSliceTrack that slices are ordered by
ts, which allows us to perform a very specific optimization which avoids rendering anything when the first slice is off the right hand side of the viewport.However, slices from the mipmap function are ordered by depth first then ts, meaning that slices are not necessarily sorted by ts. In practice, slices at lower depths usually do start before those at higher depths anyway, so this is usually not an issue.
This patch removes the optimization entirely as it seems pretty dubious whether it actually helps all that much.
Fixes: https://buganizer.corp.google.com/issues/446503267