Issue metadata
Sign in to add a comment
|
Scroll smoothness badly regressed on ToT (touch & keyboard) |
||||||||||||||||||||||
Issue descriptionNot seen in 56.0.2924.3 (today's canary). Seen on ToT (ed16c60bdef2a6fca694e312d5a77e5b93d538d2). Reproduces when I force rAF aligned touch and mouse input off. I'm seeing this essentially all pages, including: https://en.wikipedia.org/wiki/Cat for example. There's something completely crazy happening in GPU and paint land. Traces taken on wikipedia using keyboard smooth scroll. For example, Display:DrawAndSwap is consistently taking ~16ms on ToT.
,
Nov 29 2016
,
Nov 29 2016
,
Nov 29 2016
Which platform did you see this on?
,
Nov 29 2016
,
Nov 29 2016
Sorry, saw this on Linux.
,
Nov 29 2016
flackr's change in compositing scrollers that form a stacking context, or whatever that was? Seems unlikely to affect lots of pages, however.
,
Nov 29 2016
Re #7, there are no overflow scrollers on wikipedia so it would be unaffected by that change.
,
Nov 29 2016
Will need to bisect - how do I force rAF aligned touch and mouse input off?
,
Nov 29 2016
out/Release/chrome --disable-features=RafAlignedTouchInput,RafAlignedMouseInput
,
Nov 29 2016
I can't reproduce on my Linux/NVidia machine at ed16c60bdef2a6fca694e312d5a77e5b93d538d2 (revision listed in #1) Running chrome using "--enable-smooth-scrolling --disable-features=RafAlignedTouchInput,RafAlignedMouseInput" Then opening wikipedia page and holding down key on keyboard to scroll. Is there anything else that might be required to repro?
,
Nov 29 2016
Interesting, this was on my Linux/NVidia machine. Can you repro without those flags?
,
Nov 29 2016
Actually, from looking at traces and recent commits, I have an idea of what might be causing this - do you have dcheck_always_on = true (or a debug build)? The issue you're hitting seems to be from frequent calls to glGetIntegerv. Some code was added that might do this in https://codereview.chromium.org/2516063002, which is in the revision range, but would only be hit with DCHECKs enabled.
,
Nov 29 2016
Ok, confirmed my guess from #13 - this reproduces with dcheck_always_on. trchen@, it appears that the following logic introduced in https://codereview.chromium.org/2516063002 is significantly impacting performance with DCHECK enabled builds. The getIntegerv here causes a sync IPC to the GPU process - when this happens multiple times per frame the costs really add up. Is it possible to get most of this coverage with a unit test and avoid the DCHECK? 3227 #if DCHECK_IS_ON() 3228 // GetIntegerv doesn't modify the output array when GL context is lost or 3229 // in test mock. Also our GL wrapper requires output to be initialized with 3230 // 0 or -1. Assuming lost context if the output is still -1. 3231 GLint actual_scissor[4] = {-1}; 3232 gl_->GetIntegerv(GL_SCISSOR_BOX, actual_scissor); 3233 if (actual_scissor[0] == -1) 3234 return; 3235 DCHECK(scissor_rect.x() == actual_scissor[0] && 3236 scissor_rect.y() == actual_scissor[1] && 3237 scissor_rect.width() == actual_scissor[2] && 3238 scissor_rect.height() == actual_scissor[3]); 3239 #endif Thanks!
,
Nov 29 2016
Yup, I have DCHECK always on - nice catch.
,
Dec 1 2016
Tested on windows 10 touch laptop using chrome latest canary M57 #57.0.2937.0 and issue is not reproduced. @MTV team---Could anyone from MTV team look into this , as inhouse team doesn't have Linux/NVidia touch machine . Thanks!
,
Dec 12 2016
If this is for DCHECK enabled build only, is it still Pri-1? Also, ping trchen@ re #14.
,
Dec 16 2016
We removed that code recently, and ya this is about dcheck builds only so I think we're good. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by tdres...@chromium.org
, Nov 29 2016