We once ran into a request from amazon for
requestCallbackWhenElementOnscreen(). Similar concept. Goal was to know
when you got rendered --- and if there was a delay due to late stage
pipelient higns like eg image decode, or rasterization, we'd include that
in the timing.
Fundamentally, this whole space bumps up againt the :visited problem. So,
to do anything here, we need to move the community forward on :visited
mitigation, I fear.
On Fri, May 6, 2016 at 11:42 AM, Ilya Grigorik <igrigo...@google.com> wrote:
> On Wed, May 4, 2016 at 3:10 PM, Ben Maurer <ben.mau...@gmail.com> wrote:
>
>> Hey guys --
>>
>> There was some discussion internally at FB about the frame timing API
>> and that prompted a question today.
>>
>> Imagine the following JS code:
>>
>> function RenderHello() {
>> ReactDOM.render(
>> <Hello name="World" />,
>> document.getElementById('container')
>> );
>> window.performance.mark('hello_rendered');
>> }
>>
>> The developer wants to know when the Hello react component is "done" and
>> so they set a performance mark once the element is inserted into the DOM.
>>
>
> Pardon my ignorance of React.. I'm looking at the docs, and it looks like
> it accepts a third callback parameter [1]: "If the optional callback is
> provided, it will be executed after the component is rendered or updated."
>
> ^ what does the above encompass, exactly?
>
> [1] https://facebook.github.io/react/docs/top-level-api.html#
> reactdom.render
>
> However, this isn't actually correct. The user only sees the Hello element
>> once the browser paints that frame. For example, if a setTimeout() call
>> executed during the frame that took 1 second the user would only see the
>> element at the end of that second.
>>
>
>
>> This seems like a problem that the Frame Timing API would ideally help to
>> solve. But it wasn't clear that it was possible to determine this via the
>> API.
>>
>
> FT doesn't address this. As specced, it only lets you know if there was a
> slow frame... what was painted within that frame is completely opaque.
> Potentially, if we can work out the technical bits, I could see us exposing
> some high-level attribution information on what may have been the cause of
> the slow frame (e.g. script task, another frame, etc), but I don't think
> we'll ever get to element-level insights due to technical and
> privacy/security constraints.
>
> FWIW, related discussion: https://github.com/w3c/frame-
> timing/issues/53#issuecomment-206512574
>
