DebugState->CollationFrame->EndClock - DebugState->CollationFrame->BeingClock, before EndClock is set on the CollationFrame, making the Node->Duration value wrap backwards.
The oscillating ProfileBar width/length is probably only the BeginClock growing and changing the "negative"/backward-wrapped value og Node->Duration .
I was following the code using the SafeTruncateUInt64 (aka. SafeTruncateU64ToU32() as I called it cause confusion.. ) and the code Assert all over my screen.
Casey just forgot that he made that function right? There isn't another reason for not using it?
And if there there is a cost to that function should we make a AssertTruncateU64() that will be optimized out in a release build?
edit: come on guys, you have to tell me if I don't make sense, and I'm starting to wonder about this one.
There's no particular reason not to use it, but I tend not to put it in places where I know that it's not going to be a subtle bug, if that makes sense. Eg., while I certainly wouldn't tell someone _not_ to use it, just personally I tend not to assert things when I'm not scared about them :)
So in this case, that was exactly what happened - eg., the bug was obvious and I immediately found it. The case I'm usually worried about when I do SafeTruncate is that it is something that will _usually be correct_, but then sometime somebody will try to use that function with some large value and then spend a ton of time debugging because it's in code that's really old and assumed to be working / not under suspicion.
Does that make sense?
So that's why I don't _usually_ SafeTruncate, but it should be a totally fine practice to do that if you wanted to.