Noticeable lag between rendering and actions being sent

[html-next]

Noticeable lag between rendering and actions being sent

[antidis]

I'll try do something like that tomorrow. I suspect you're on SF time, and I'm in Dublin, so it may be tricky to arrange remote debugging. @GavinJoyce maybe we can pair on this tomorrow afternoon?

[pzuraq]

Merged the change, let me know if you're still having issues @antidis @GavinJoyce!

[antidis]

To be specific:

• Scrolling to the end of the currently-loaded content takes place first.
• I hit the end and nothing seems to happen. I can scroll back up fine—the browser has not locked.
• Loading kicks in a short time later (the loading function in this case is just a task that throws a few hashes into the rows array, then notifies Ember of the change).

It's hard to get the timings precise as it's hard to map my inputs precisely to the timeline above, and the browser window with the above timeline has been lost. When I generated a profile a while ago, it appears to show a ton of time spent idling but not much else.

This behaviour vanishes when run.next is replaced with run.schedule('afterRender', ... here: 4290749#diff-dd82fd2ab5100320f9dd5248149349efR312 - but as Chris mentions, this isn't a fix.

I had hoped to get some more information to help my own digging into the situation—we're not quite at the stage where I have a twiddle to show the behaviour, but I'll try create on tomorrow.

We're on Ember 2.11.3.

[pzuraq]

Interesting. Yeah, it's weird that the browser is spending so much time doing nothing, run.next should just schedule a new runloop in a setTimeout which would generally run in between scrolls/RAFs. Not sure why it's being pushed out that much, but that's definitely way too much of a delay. @runspired any insights on this?

@antidis could you possibly paste the template usage and the actions that caused this so we can try to debug? Or if you could make an ember-twiddle or branch on the dummy app that demonstrates the issue that would be ideal

[antidis]

Working on the twiddle this morning. Will post then.

[antidis]

Here's a stripped-down and sanitised version of the addon we're hoping to include vertical-collection in:

https://github.com/antidis/vertical-collection-bug-demo

The problem still occurs, and occurs reliably. Interestingly, this problem does not occur in Firefox. A colleague suggested that this may indicate an RSVP bug.

[antidis]

The problem also does not occur in Safari. This may be hitting a Chrome bug.

[pzuraq]

Weird, I'm not able to reproduce locally:

There isn't really a noticeable gap between when the RAF ends and the scroll event fires. If the loading event were a longer running async task then there could be lag, definitely, but that's not really something we can control.

Maybe there's a hardware component to this as well?

[antidis]

I sure hope not.

This is on a mid 2015 Retina MBP. Chrome version: 57.0.2987.133 (64-bit). Happens in HiDPI and non-HiDPI resolutions too. We have other test hardware available, but so far we've only tested it on (likely 2015) MBPs.

What hardware are you running? If we find out, we can hopefully track it down.

[pzuraq]

I'm running El Capitan on a 2013 rMBP, Chrome Version 57.0.2987.133 (64-bit)

Any chance you could take a video of it in action? I'll try to reproduce locally but I can't really help until I do 😅

[antidis]

[pzuraq]

Ok yeah, super noticeable and nothing like what's happening on my machine. WEIRD.

Definitely a priority to get this fixed before 1.0.0, even if it's not an issue in this library directly.

[pzuraq]

@antidis could you possibly send a couple of timeline screenshots with these sections zoomed in?

Would help to get a better look at what's going on at those points in time. Also, I'm up for remote debugging via Screenhero or something like that if you can do that.

[GavinJoyce]

Maybe there's a hardware component to this as well?

Another data point, I can reproduce this issue on my machine in both Chrome 57.0.2987.133 (64-bit) and Chrome 59.0.3069.0 canary (64-bit) with no addons on MacBook Pro (Retina, 13-inch, Early 2015) running OSX 10.12.4 (16E195)

[runspired]

Chrome aggressively throttles and can sometimes even drop setTimeout calls during scroll. This seems overly aggressively throttled though.

As I think about this, we may have to move to afterRender scheduling for the microtask semantics to avoid this.

One thing to note, with scroll, it is never guaranteed that you'll be given the chance to respond in a reasonable amount of time. Not unique to Chrome, but Chrome has always been more aggressive in this area.

[pzuraq]

Makes sense, we can move the scheduling to afterRender and add a note in the Perf section in the docs (which needs to be added). As long as actions are short and simple, or schedule things asynchronously themselves, it should be fine.

[antidis]

@pzuraq Testing it locally, and the problem seems to have disappeared. Thanks!