I don't think removing this note is consistent with Chrome's implementation

It's true, but it seems chrome's implementation is not translatable to spec language, as it relies on that complex rendering pipeline implementation detail. Which means currently FCP is not apples to apples comparison (no pun intended) across browsers, as mentioned by the WebPageTest folks. I find that unfortunate but I'd prefer that the spec was more normative and chrome can make its own decision about whether to go with it, do its own thing, or propose something else...

I don't think removing this note is consistent with Chrome's implementation

It's true, but it seems chrome's implementation is not translatable to spec language, as it relies on that complex rendering pipeline implementation detail. Which means currently FCP is not apples to apples comparison (no pun intended) across browsers, as mentioned by the WebPageTest folks. I find that unfortunate but I'd prefer that the spec was more normative and chrome can make its own decision about whether to go with it, do its own thing, or propose something else...

Would it make sense for the spec note that developers should not expect the values to be comparable, and point to this discrepancy as an example then?

I don't think removing this note is consistent with Chrome's implementation

It's true, but it seems chrome's implementation is not translatable to spec language, as it relies on that complex rendering pipeline implementation detail. Which means currently FCP is not apples to apples comparison (no pun intended) across browsers, as mentioned by the WebPageTest folks. I find that unfortunate but I'd prefer that the spec was more normative and chrome can make its own decision about whether to go with it, do its own thing, or propose something else...

Would it make sense for the spec note that developers should not expect the values to be comparable, and point to this discrepancy as an example then?

The values are not comparable because we chose to keep the original non-interoperable implementation in chrome... it's a valid choice to do something non-interoperable, as interoperability is not everything. However, since the main idea of standards is interoperability & consensus, I think we should remove the note, as it's vague anyway, and live with Chrome being non-compliant with the normative part of the standard.

I don't think removing this note is consistent with Chrome's implementation

It's true, but it seems chrome's implementation is not translatable to spec language, as it relies on that complex rendering pipeline implementation detail. Which means currently FCP is not apples to apples comparison (no pun intended) across browsers, as mentioned by the WebPageTest folks. I find that unfortunate but I'd prefer that the spec was more normative and chrome can make its own decision about whether to go with it, do its own thing, or propose something else...

Would it make sense for the spec note that developers should not expect the values to be comparable, and point to this discrepancy as an example then?

The values are not comparable because we chose to keep the original non-interoperable implementation in chrome... it's a valid choice to do something non-interoperable, as interoperability is not everything. However, since the main idea of standards is interoperability & consensus, I think we should remove the note, as it's vague anyway, and live with Chrome being non-compliant with the normative part of the standard.

If we had a new browser implementing this API, shouldn't they aim to provide a timestamp that is close to the actual time when the user sees pixels on the screen? I don't think just removing the note is correct. Sure, perhaps we don't have a clear processing model for how that should look like and the spec states that the timestamp should be much earlier, but I think having that flexibility in the spec is preferable to pretending that the algorithm is fully interoperable.

In conversations with @mmocny, he mentioned that he may be interested in trying to more closely define the concept of "presentation times" and tie that to the various specifications that can benefit from it (Paint Timing, LCP and Event Timing, at the very least).

Might be worthwhile to keep the note (or replace it with a more accurate one) until this work happens.