The Node->Duration calculation

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.

- Casey

Yeah that makes sense, since it was at the end of the stream I wasn't sure how easy it was to find.

I'm following the code, but I'm not always "following" the newest code if you know what I mean.