New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 289461 link

Starred by 10 users

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug


Show other hotlists

Hotlists containing this issue:
Hotlist-1
Hotlist-1


Sign in to add a comment

Occasional jumpy scrolling on Android

Project Member Reported by skyos...@chromium.org, Sep 11 2013

Issue description

Chrome rev 222441.

Chrome on Android occasionally goes into a state where scrolling is very "jumpy" for a few seconds. Visually it looks like the page is scrolling down, jumping a bit back and then scrolling down more.

This seems to be hard to reproduce; I had to take about 20 videos before I caught it. Here's a 240 fps video where you can see the bug at around 1:30:

https://docs.google.com/a/google.com/file/d/0B7i1yhITiW6lcVh3NTdTVkJrYjg/edit?usp=sharing

The bug also happens with the WebView.
 
Labels: M-31
Owner: skyos...@chromium.org
Status: Assigned
Cc: boliu@chromium.org joth@chromium.org klo...@chromium.org aelias@chromium.org

Comment 3 by klo...@chromium.org, Sep 11 2013

Do you mean the scrolling back up from 1:13 to 1:17 assuming you didn't fling? I don't see the weird around 1:30 in the video.
Labels: -M-31 M-30 ReleaseBlock-Stable
Sorry it's really hard to see in the video, but the problem shows up best around 1:27 when I'm scrolling down. See how the page is jumping up and down?

We think this is a regression from M29.

It may be a coincidence, but so far all the reports have been on Qualcomm devices and we've recently disabled virtual GL contexts on them.
Cc: siev...@chromium.org
Thanks Grace, this seems to repro easily with Settings => Help. Sample video: https://docs.google.com/a/google.com/file/d/0B7i1yhITiW6lbldHeEdrVnVHRWs/edit?usp=sharing
Confirmed that turning virtual contexts back on fixes this. I'll write a patch to do that.

Attached two traces with different virtual context settings. There's nothing obviously different between them, but the help page is still very janky after enabling virtual contexts.
trace-with-virtual.html.gz
1.3 MB Download
trace-without-virtual.html.gz
1.3 MB Download

Comment 9 by boliu@chromium.org, Sep 11 2013

Wonder what's causing this for webview, which should always have virtual context enabled. I'm guessing you don't have reliable repro steps for webview?
The webview part was only hearsay; I didn't witness it happening. We'll check with the original reporter.
At this point it seems like the WebView issue was unrelated. We should still try to figure out what is going on in the GL side when this happens.
Sami, if you load the same help page in the tab, e.g. menu->help directly, I can't reproduce the "shaky" as it does in settings->help. Both should have the same config. And I don't see janky when it is loaded in the tab.
Cc: vangelis@chromium.org
Was just chatting with Sami and we were wondering if QC needs a fence here for the context switch (similar to the ARM Nexus 10 driver).


It doesn't look like a fence on every context switch fixes the problem (if I'm looking at the same issue), such as:

ui/gl/gl_context_egl.cc b/ui/gl/gl_context_egl.cc:

+  GLFence* fence = NULL;
+  if (GLContext::GetCurrent())
+    fence = GLFence::Create();
+
   if (!eglMakeCurrent(display_,
                       surface->GetHandle(),
                       surface->GetHandle(),
     return false;
   }
 
+  if (fence)
+    fence->ServerWait();

(Note: needs https://codereview.chromium.org/23619031/)


ui/gl/gl_fence.cc b/ui/gl/gl_fence.cc:
@@ -96,6 +96,10 @@ class EGLFenceSync : public gfx::GLFence {
...
+  virtual void ServerWait() OVERRIDE {
+    eglWaitSyncKHR(display_, sync_, 0);
+  }

And I don't see the issue from #12 (settings -> help) being affected by anything I tried, including turning virtual contexts back on.


Looks like the difference between Settings => Help and Help in a normal tab is that at some point the browser compositor starts running twice per vsync. This makes the help page feel very janky and for some reason triggers the out of order frames without VC. I think this is an entirely separate bug (filed crbug.com/290088) that just happens to trigger this one.

> It doesn't look like a fence on every context switch fixes the problem (if I'm looking at the same issue)

Did you see the video in comment #7? The bug is pretty obvious when it happens.

If fences don't fix this, this could be something else like the earlier scissor bug where everything was getting clipped.

> And I don't see the issue from #12 (settings -> help) being affected by anything I tried, including turning virtual contexts back on.

Weird. Are you testing on Nexus 4 or something else? Virtual contexts definitely make the bug go away here.

Adding a glFinish() in NativeViewSurfaceEGL::SwapBuffers fixed the flickering, so this is probably just a case of missing synchronization. I also tried glFlush() but it didn't make a difference.

I also checked that the bug doesn't happen at all on the 2012 Nexus 7.
Labels: Merge-Requested
Requesting merge to M30 since this is a very visible regression.
Project Member

Comment 18 by bugdroid1@chromium.org, Sep 12 2013

------------------------------------------------------------------------
r222769 | skyostil@chromium.org | 2013-09-12T13:07:19.468788Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/gpu/config/gpu_driver_bug_list_json.cc?r1=222769&r2=222768&pathrev=222769

gpu: Re-enable virtual contexts on Qualcomm

Non-virtual contexts on Qualcomm GPUs sometimes cause out-of-order
frames to be displayed, so turn GL context virtualization back on.

BUG= 289461 

Review URL: https://chromiumcodereview.appspot.com/23460029
------------------------------------------------------------------------
A client side wait seems to work, but we can't really use it like this because of the perf hit.

--- a/ui/gl/gl_surface_egl.cc
+++ b/ui/gl/gl_surface_egl.cc
@@ -362,12 +362,22 @@ bool NativeViewGLSurfaceEGL::IsOffscreen() {
 }
 
 bool NativeViewGLSurfaceEGL::SwapBuffers() {
+  EGLSyncKHR sync = 0;
+  if (GLContext::GetCurrent()) {
+    sync = eglCreateSyncKHR(GetDisplay(), EGL_SYNC_FENCE_KHR, NULL);
+  }
+
   if (!eglSwapBuffers(GetDisplay(), surface_)) {
     DVLOG(1) << "eglSwapBuffers failed with error "
              << GetLastEGLErrorString();
     return false;
   }
 
+  if (sync) {
+    eglClientWaitSyncKHR(GetDisplay(), sync, 0, EGL_FOREVER_KHR);
+    eglDestroySyncKHR(GetDisplay(), sync);
+  }
+
   return true;
 }

Daniel, I tried your patch from #14 on a Nexus 10 and it didn't fix the ordering issues. There must be something we're missing here :\
Hmm, disregard that. The Nexus 10 I have is shows horrible flickering even with Chrome ToT. Not sure what is going on.
Cc: epenner@chromium.org
One more experiment I want to try: real contexts *and* state restore on every context switch

Comment 23 by epenner@google.com, Sep 12 2013

This is a total shot in the dark, but one thing that occurs rarely is two compositor frames being rendered in the same swap. If there was a driver bug in how the FBOs are deferred, it could have this effect... Again though, total shot in the dark.

Comment 24 by epenner@google.com, Sep 12 2013

It would also be interesting to see in DEBUG, if we are getting the blue clear or not.
Cc: kareng@google.com
Opened  bug 290876  about a similar looking problem on Nexus 10.
#24: I tried enabling the blue debug clear but it didn't show up. Good idea about the potential deferral bug, but I'm not sure how to test that theory.

Comment 28 by kareng@google.com, Sep 13 2013

looks like things are still not working right?  do you want merge?
Please merge the CL in #18 to M30.

Comment 30 by kareng@google.com, Sep 13 2013

Labels: -Merge-Requested Merge-Approved
ok r222769 approved.
Project Member

Comment 31 by bugdroid1@chromium.org, Sep 13 2013

Labels: -Merge-Approved merge-merged-1599
------------------------------------------------------------------------
r223064 | skyostil@google.com | 2013-09-13T16:55:53.631324Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/gpu/config/gpu_driver_bug_list_json.cc?r1=223064&r2=223063&pathrev=223064

Merge 222769 "gpu: Re-enable virtual contexts on Qualcomm"

> gpu: Re-enable virtual contexts on Qualcomm
> 
> Non-virtual contexts on Qualcomm GPUs sometimes cause out-of-order
> frames to be displayed, so turn GL context virtualization back on.
> 
> BUG= 289461 
> 
> Review URL: https://chromiumcodereview.appspot.com/23460029

TBR=skyostil@chromium.org

Review URL: https://codereview.chromium.org/23460039
------------------------------------------------------------------------
I tried Daniel's patch from #14 on a Nexus 10 with a fix for  bug 290876  and I still see occasional out of order frames. However, it is even worse with eglClientWaitSyncKHR than eglWaitSyncKHR. Had it worked correctly then we could've assumed that there is a synchronization bug in the Nexus 4 driver, but now I think we still need to narrow this down more.

I'll try Daniel's idea from #22 next.
No luck with forcing state restores. Basically I'm calling RestoreState() in GLES2DecoderImpl::MakeCurrent().
Project Member

Comment 34 by bugdroid1@chromium.org, Sep 18 2013

------------------------------------------------------------------------
r223910 | sievers@chromium.org | 2013-09-18T18:38:35.556563Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/gpu/config/gpu_driver_bug_list_json.cc?r1=223910&r2=223909&pathrev=223910

Revert 223064 "Merge 222769 "gpu: Re-enable virtual contexts on ..."

BUG=292734

> Merge 222769 "gpu: Re-enable virtual contexts on Qualcomm"
>
> > gpu: Re-enable virtual contexts on Qualcomm
> >
> > Non-virtual contexts on Qualcomm GPUs sometimes cause out-of-order
> > frames to be displayed, so turn GL context virtualization back on.
> >
> > BUG= 289461 
> >
> > Review URL: https://chromiumcodereview.appspot.com/23460029
>
> TBR=skyostil@chromium.org
>
> Review URL: https://codereview.chromium.org/23460039

R=skyostil@chromium.org
TBR=skyostil@google.com

Review URL: https://codereview.chromium.org/23694038
------------------------------------------------------------------------
Project Member

Comment 35 by bugdroid1@chromium.org, Sep 18 2013

------------------------------------------------------------------------
r223911 | sievers@chromium.org | 2013-09-18T19:08:36.423015Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1599/src/content/browser/gpu/gpu_data_manager_impl_private.cc?r1=223911&r2=223910&pathrev=223911

Partially Revert 221100 "Merge 220427 "Android: Disable virtual contexts f..."

This turns virtual contexts back on for QC devices.

BUG= 289461 ,292734

> Merge 220427 "Android: Disable virtual contexts for NV and QC on..."
> 
> > Android: Disable virtual contexts for NV and QC on new OSes
> > 
> > BUG= 280609 ,163464
> > R=klobag@chromium.org, piman@chromium.org
> > 
> > Review URL: https://codereview.chromium.org/23483023
> 
> TBR=sievers@chromium.org
> 
> Review URL: https://codereview.chromium.org/23604040

TBR=sievers@chromium.org

Review URL: https://codereview.chromium.org/24153016
------------------------------------------------------------------------
Status: Fixed

Comment 37 by bph...@gmail.com, Oct 14 2013

Jumping still exists in latest beta version.

bphilp: On which device and page are you seeing the problem? It might be a different issue.
Labels: -Cr-UI-Input-Touch-Screen Cr-Internals-Input-Touch-Screen

Comment 40 by Deleted ...@, Dec 29 2013

This regression happens constantly on Acer Iconia B1-710 running Android 4.1.2 and the latest Chrome version. Reverting to the factory Chrome version (26.something) fixes the problem.

Comment 41 by Deleted ...@, May 25 2015

Nf
If you ask me, the video was fine. The problem would have been caused by a disrupted or distorted signal. That is very capable of showing a Flickr picture or is actually frames not setting well for a moment. You say bug, I say very logical explanation is available. There may not ever be a precise way of knowing Egan a small occurrence happens like this. I believe anything that uses energy to exist, will always be susceptible to these bugs. Improving other things that deal with a different area of the same issue would be a good idea to look at. I, personally would start with one of the easiest and go from there. This will end up being a good idea to always have a backup for a backup. 
Hi

T

Sign in to add a comment