New issue
Advanced search Search tips

Issue 735631 link

Starred by 2 users

Issue metadata

Status: Archived
Owner:
Closed: Aug 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocking:
issue 731255



Sign in to add a comment

mushrome: Ozone DRM display tearing

Project Member Reported by kylec...@chromium.org, Jun 21 2017

Issue description

When running mushrome on link with an external display attached I was able to produce screen tearing. The internal and external display were both on and they were configured in extended mode.

There is an unrelated bug with window position that causes a window to rapidly jump between two positions when it's being dragged. This makes it easy to see the screen tearing.
 
Cc: sky@chromium.org

Comment 2 by sky@chromium.org, Aug 15 2017

Blocking: 731255
Owner: kylec...@chromium.org
Status: Assigned (was: Available)
I can take a look at this. We need to plumb the vsync signal from Ozone DRM to our BeginFrameSource. Right now we are just using a DelayBasedBeginFrameSource that ticks a timer without external input.
This is not a vsync issue after all. The vsync params are plumbed correctly out of Ozone DRM and used to update the DelayBasedBeginFrameSource. I think that is working correctly.

Experimenting a bit more, it turns out the buffers for the two displays are somehow getting mixed up. This happens frequently when dragging windows around.
Cc: jamescook@chromium.org
Status: Started (was: Assigned)
I sent out https://crrev.com/c/621529 for it.
Project Member

Comment 6 by bugdroid1@chromium.org, Aug 22 2017

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

commit 8eebde3066399d63c8abe2f22bbcf0ad010c419d
Author: kylechar <kylechar@chromium.org>
Date: Tue Aug 22 21:50:39 2017

mus: Fix screen tearing on Chromebook.

If you were running mus/mash on a Chromebook with two displays then
there would be constant screen tearing. It turns out that the buffer for
one display was sometimes ending up on the other display. There are two
InProcessCommandBuffers, one for each display, that independently
allocated IDs from CreateImageCHROMIUM starting at 1. This resulted in
ID collisions.

Make all InProcessCommandBuffers allocate IDs for CreateImageCHROMIUM
from a global AtomicSequenceNumber to ensure there are no ID collisions.

Bug:  735631 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I4501afe854041304b4860f0a2a67ca5c1a0e1df9
Reviewed-on: https://chromium-review.googlesource.com/621529
Commit-Queue: kylechar <kylechar@chromium.org>
Reviewed-by: weiliangc <weiliangc@chromium.org>
Reviewed-by: Victor Miura <vmiura@chromium.org>
Cr-Commit-Position: refs/heads/master@{#496458}
[modify] https://crrev.com/8eebde3066399d63c8abe2f22bbcf0ad010c419d/gpu/BUILD.gn
[modify] https://crrev.com/8eebde3066399d63c8abe2f22bbcf0ad010c419d/gpu/ipc/client/DEPS
[modify] https://crrev.com/8eebde3066399d63c8abe2f22bbcf0ad010c419d/gpu/ipc/client/gpu_in_process_context_tests.cc
[modify] https://crrev.com/8eebde3066399d63c8abe2f22bbcf0ad010c419d/gpu/ipc/in_process_command_buffer.cc
[modify] https://crrev.com/8eebde3066399d63c8abe2f22bbcf0ad010c419d/gpu/ipc/in_process_command_buffer.h

Status: Fixed (was: Started)

Comment 8 by dchan@chromium.org, Jan 22 2018

Status: Archived (was: Fixed)

Sign in to add a comment