Spun off from bug 913909. STR: 1) load a suitable page of text (http://www.gutenberg.org/files/11/11-h/11-h.htm) 2) fling the page result: scroll jitter, particularly when you approach the end of the fling.

I can reproduce this - it's basically compositor jank. I uncommented the COMPOSITOR_PERFORMANCE_WARNING define in gfx/layers/ipc/CompositorParent.h and was seeing output indicating inter-frame times of > 100ms on my surface pro (non-debug build). We will need to profile stuff in the compositor to see what's taking so much time - it might be the upload or it might be something else.

Is bug 86555 really blocking this bug? Do you get not reasonable profiles with the steps I listed there? With bug 918825 that landed you should be able to get a nice profile with the frame breakdowns which makes profiling scrolling jank a piece of cake.

After talking with BenWa a bit I was able to get a multi-threaded profile while panning on the url in comment 0: http://people.mozilla.org/~bgirard/cleopatra/#report=1cb1877e852ee7352f4bb5de323614bd5a131adf I'm not sure I'm reading it correctly but it seems like a lot of the compositor thread time is being spent in NtGdiDdDDIAcquireKeyedMutex2, called by mozilla::layers::DeprecatedTextureHostDXGID3D11::LockTexture(). Somebody who knows what that function is and what it does should probably look into this.

Bas says he needs a profile with samples from the content thread as well, so adding a dependency on bug 927979.

Another key interface where we can see this is in the start tab. If you fill out your start tab with a lot of browser history and random bookmarks such that it has a lot of scroll length, you'll notice that the scroll animation tends to stutter at certain points in the scroll. This is somewhat surprising since the start tab is totally static after it loads and as such should just be a large texture we are just shifting around.

If it gets bigger than the displayport size then we will still be doing uploads and so the jitter might still happen. We don't draw the entire thing if it's too big because that will take up too much memory.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #6) > If it gets bigger than the displayport size then we will still be doing > uploads and so the jitter might still happen. We don't draw the entire thing > if it's too big because that will take up too much memory. Since we can control the width via logic in the tab, would it be acceptable to use setDisplayPortForElement to max out the display port and force a full render?

If you're fine with the memory hit then I have no problem with it. Note that the displayport heuristics in the APZC might still request repaints but if so that's an APZC bug.

Likely omtc related rather than apzc. I think it's bad enough that it should block dec. 9th rollout. At the very least we should investigate to see if we can improve scroll fluidity.

I'm not seeing this anymore on text pages. The about:start tab has its own bug.