Given how close Twitter light is to the native experience already and the press around it, I think it's strategically important that we try to fix this.

On the GPU side, there are some long bursts of GPU decoder work (such as 5,206.231 ms) that Sunny's GPU scheduler work should help.

I'm also seeing some long calls to GLES2DecoderImpl::ClearLevel.  Normally those should be entirely avoided, so we should look at what Ganesh may be doing here.

Indeed, there is a bigger difference between Ganesh on and off. When it is off, I do see checkboard/white space, but it is much smoother.

I locally applied Sunny's GPU scheduler patch http://crbug.com/2814843002 and it does clear up almost all of the jank on my Galaxy S7.  I would even say that there are fewer janks than the Android native app.

But this comes at the cost of quite visible checkerboarding if you fling too fast.  The twitter native app never has checkerboard regions per se (although it shows solid colors in place of not-yet-decoded images).

Sounds great, thanks Alex!  Given the excessive main-thread work, lots of checkerboarding perhaps isn't surprising.  I know others are working with Twtitter to reduce the total main thread work they're doing.

aelias@ I made a change to the CL to reduce checkerboarding and main thread latency. There's still quite a bit of checkerboarding but maybe less than before?

Should we deprioritize image uploads and let those only happen when we get out of smoothness takes priority mode? That way we can keep rasterizing more text/paths while scrolling while checkerboarding images and maybe that's a better experience?

Completely suppressing image uploads during scrolling sounds like a too heavy hammer, if that's what you're suggesting.  I'm not sure we fully understand the cause of the checkerboarding yet either?

I think we should probably get the scheduler infrastructure landed first and try out various policy changes after that.

It looks like Sunny is the correct person to own this then, until such time as the scheduler infrastructure changes land.

Image-checkering could help this kind of case, taking the place of what the native app does in place not-yet-decoded images.

Looking at traces though I would say the long main thread script (100~500ms) is the bigger fish to fry.

There are also some CommandExecutor::PutChanged tasks that seem to take a lot of CPU self time (including one in the above trace that's 91ms).  Is that worth digging into separately, maybe adding some sub-traces for?