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

Issue 840267 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 0
Type: Bug



Sign in to add a comment

Graphic and video broken at veyron devices when scrolling up/down playing video

Project Member Reported by hiroh@chromium.org, May 7 2018

Issue description

Reproduce step:
1. Access http://crosvideo.appspot.com/?codec=h264
2. Play video in the page
3. Scroll down/up randomly the page.

Expected Result:
Video is playing smoothly.

What happens instead:
Break not only video and but also graphic.


I bisected and found cause CL is https://chromium.googlesource.com/chromium/src/+/f634aa2d0ca1cb9c08c46e4266d43c46a7c34147.
Reverting this CL on Chrome ToT resolved this issue.

The CL breaks some CTS failures and video_VideoSeek.
video_VideoSeek is the test for video seeking as its name.
As far as I tested on crosvideo.appspot.com, seeking merely videos doesn't break video.
I guess graphic breakage is triggered by stressing graphics.
video_VideoSeek changes video frame very quickly by playing and seeking locally stored video.
on crosvideo.asspot.com, it is difficult to change quickly so much because the video source is in the external server.

dcastagna@, could you investigate this failure and decide to revert the CL or submit a fix CL?
 

Comment 1 by hiroh@chromium.org, May 7 2018

Summary: Graphic and video broken at veyron devices when scrolling up/down playing video (was: Graphic and video broken at minnie when scrolling up/down playing video at veyron devices)

Comment 2 by hiroh@chromium.org, May 7 2018

Labels: -Pri-1 Pri-0
Some test in CQ may be failed by this CL. Let me set higher priority.
Status: Started (was: Assigned)
If we decide to revert that CL, we'd need to revert this one too: https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1022991, otherwise we'll regress on drm-atomic devices.

I'm looking into it right now.
crrev.com/c/1048245 for the fix.
Project Member

Comment 5 by bugdroid1@chromium.org, May 7 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fc6cbcd44438602c87e1022e7479eee305eec99e

commit fc6cbcd44438602c87e1022e7479eee305eec99e
Author: Daniele Castagna <dcastagna@chromium.org>
Date: Mon May 07 21:31:03 2018

Avoid creating overlay validator with no strategies.

In crrev.com/c/1022872 we changed the logic of how we initialize
CompositorOverlayCandidateValidatorOzone.

We erroneously changed the logic to always instantiate
CompositorOverlayCandidateValidatorOzone even when no strategies were
specified.

This broke legacy devices. This CL makes sure not to instantiate
the validator if not needed.

Bug:  840267 ,  834015 
Test: Play video on veyron_minnie
Change-Id: Ibde65689c05d38a3fe22d81748db8d21f89d725e
Reviewed-on: https://chromium-review.googlesource.com/1048245
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Commit-Queue: Daniele Castagna <dcastagna@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556575}
[modify] https://crrev.com/fc6cbcd44438602c87e1022e7479eee305eec99e/content/browser/compositor/gpu_process_transport_factory.cc

Status: Fixed (was: Started)

Comment 7 by hiroh@chromium.org, May 8 2018

Thank you for fixing quickly.
Do you have a test to catch this issue?
If you don't have, could you think about adding a test to catch this issue
before merging?
Cc: avkodipelli@chromium.org
Status: Verified (was: Fixed)
Verified on 10718.4.0, 68.0.3440.4.

Sign in to add a comment