explain relationship to DOM/JS dirtiness versus hardware vsync signals

[dbaron]

Given the request to have issues in your own repository, I'm copying the comment at w3ctag/design-reviews#415 (comment) here (with a bit of delay!):

---

@hober @plinss and I are looking at this again at our Cupertino face-to-face meeting, and we pulled in @smfr since he's here.

One of the things that came out of the discourse thread mentioned in the previous comment that we discussed a bit is that it sounds like the intent (although that isn't clear from the explainer, and probably should be!) is that isFramePending should become true as a result of some vsync trigger that comes from the OS, not as a result of the JS that dirties the DOM or style that ends up triggering the need for a repaint. This actually makes me a little bit more worried about interoperability here: it's not clear to me how interoperably those OS signals are defined, whether they behave in different ways on different platforms, e.g., how much does the time between when isFramePending becomes true and when the main-thread rendering is done vary between platforms? how much does this differ for a page in a background tab? also, when does isFramePending become unset?

We also talked a little bit about whether there are :visited link history-sniffing attacks that would result from this. My assertion was that it didn't seem like a big deal because we should be attempting to audit from the side of not having different performance characteristics whether or not links are visited. But @smfr pointed out that there could be optimizations (e.g., those based on display-list diffing) that might need to be disabled in that case, and which could (depending on how it's defined) affect whether isFramePending is true.

It might help the review progress a bit if the explainer tried to flesh out the answers to these questions a little bit more. And if you do update the explainer in response to this, please ping us in this issue so we know to take another look at it.