I've seen it happen on Windows Server 2008 R2, Windows Server 2012, Windows 8, and Windows 8.1, both over RDP and locally. I demonstrated the problem, which is extant in the latest release, for Ben the other lunchtime.
What seems to be happening is that the bars in the timing columns, and the lines in the navbar on the right, are being normalised against the overall timings for the period selected in the timeline, NOT against the longest running line in the file. This is a problem because if, for example, you're looking at wall clock time, the real performance problems are generally not in the supposedly most expensive stack trace (which is often something like "waiting for synchronization").
As I say the issue is that you have to find the most expensive lines of code by inspection, which is obviously error prone, not to mention time-consuming for larger source files.
Hope that's helpful.