Scott said he has another prototype that limits changes to PaintTiming. I'd love to see that (although this is not high priority)

Here's the other prototype that takes a different approach: https://chromium-review.googlesource.com/c/576352/.

It is essential that single frame has single timestamp and the latter approach does introduce a potential race. Capturing timestamp per frame in compositor does not seem like a big overhead, so we could unconditionally capture it. Let me see if we have an existing timestamp laying around we could reuse.

IIRC +brianderson was opposed to always generating a new timestamp per frame in compositor 

The performance overhead of generating a new timestamp per frame shouldn't be too big - Brian, is the performance overhead your concern?

Scott, can you comment on what exactly the proposal is here that has overhead issues?
IIUC this is not just overhead of a single timestamp but the cost of always queueing a swap promise (regardless of whether it is needed) and consequent IPCs 
(hard to say without knowing the proposal)

Sure, IIRC the only concern about the overhead is related to computing the timestamp once per frame, as it can be slow on some platforms. And, since we aren't queuing a swap promise for each frame (for purposes of FP/FCP/etc.), this adds unneeded overhead. I'm not aware of overhead concerns for queuing unnecessary swap promises.

In the initial prototype/proposal, I added methods to the SwapPromise interface to minimize overhead but provide a consistent timestamp, i.e. we added a NeedsTimstamp() method so it is only computed if needed, and the same timestamp is passed to all SwapPromises through DidSwap().

This is kind of gross, so I think it's being proposed just to always compute and pass the timestamp to DidSwap(), so it's cleaner (we would also need the timestamp in DidNotSwap() to be consistent, since we are now computing a timestamp there as well).

So, TL;DR, we want one timestamp per frame, but we only queue swap promises for some frames. So, is it too much overhead to compute it in ALL cases, even if it isn't needed?

The overhead may be acceptable.
(In the worst case it's on the order of ~10us [Android] every ~16ms?)

Sunny, Brian - any thoughts? 

Brian and I chatted this morning about this, and he's thinking there might be a timestamp that can be plumbed through to the SwapPromise machinery. The current thought is to try to reuse an existing timestamp, and modify the SwapPromise interface adding a timestamp parameter to both DidSwap() and DidNotSwap().

Brianderson: Ping!

Is there any update for this bug?

Ping. And one option to fix the bug would be only queueing a swap promise if none is queued in PaintTiming (and processing all available paints within the single promise). I did something like this for EventTiming.

Brian is off Chrome now. Marking untriaged.

This bug is stale. Plan is to move to presentation timestamp at some point. +sadrul because I don't know if those have the same problem as swap timestamps.

Presentation-timestamps will not have this issue.