Image tearing on try.matterport.com |
|||||||
Issue descriptionChrome Version: 58.0.3029.28 OS: Android N Device: Pixel, Pixel XL VR Services: 1.3.149854881 When you move your head around, the image seems to tear or split. This does not happen in M57 (57.0.2987.117) so it seems to be a new regression. What steps will reproduce the problem? Start with Daydream as the default headset (1) go to https://try.matterport.com/virtual-reality/webvr/ and scroll down to select the Hawaiian Oceanside Villa (2) Select the vr icon in the bottom right hand corner and follow DON flow prompts What is the expected result? head movement happens without distortion to the image What happens instead? The image seems to tear or split in a couple places briefly when you move your head around.
,
Mar 21 2017
M59 is doing something much worse. The image tears from the center and smears the content around with movement. Its a bit hard to describe. Here's a couple screenshots.
,
Mar 21 2017
That was 59.0.3046.3
,
Mar 21 2017
I can reproduce, this is very odd. Looks like it's not properly clearing the screen on each new frame, content is accumulating and getting drawn on top of each other. The tearing effect may be due to Z buffer fighting for near-coplanar textured triangles. Is it doing anything unusual with your rendering pipeline or canvas? I'll keep looking, but this is definitely unexpected.
,
Mar 21 2017
Found it, we're supposed to be clearing the screen each frame if preserveDrawingBuffer is false. This used to happen as a side effect of compositing, but we're no longer doing that. Working on a fix.
,
Mar 22 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e214268ec8e017ccaafe1dda4dca58015456f7a9 commit e214268ec8e017ccaafe1dda4dca58015456f7a9 Author: klausw <klausw@chromium.org> Date: Wed Mar 22 06:49:14 2017 WebVR: clear screen after submit if preserveDrawingBuffer is false. That's part of the spec, normally compositing does so but that's paused while presenting. BUG= 703378 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 Review-Url: https://codereview.chromium.org/2766553004 Cr-Commit-Position: refs/heads/master@{#458648} [modify] https://crrev.com/e214268ec8e017ccaafe1dda4dca58015456f7a9/third_party/WebKit/Source/modules/vr/VRDisplay.cpp [modify] https://crrev.com/e214268ec8e017ccaafe1dda4dca58015456f7a9/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp [modify] https://crrev.com/e214268ec8e017ccaafe1dda4dca58015456f7a9/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.h
,
Mar 22 2017
Should be fixed by this CL, but as of now the change hasn't made it to a canary build. Can you please verify once that has rolled out? Thanks for catching it!
,
Mar 23 2017
Looks good in today's canary 59.0.3049.0.
,
Mar 29 2017
The issue still exists in M58 - not as substantial as in M59, but as described in #1. Should I log a new issue since the M59 issue which is fixed seems a bit different?
,
Mar 29 2017
New issue please, but fair warning that we're unlikely to be able to do much about issues in M58 at this point unless it's a severe issue and/or has a very small and obviously correct fix. I suspect this one would be neither of those.
,
Mar 29 2017
,
Mar 29 2017
OK thanks. I logged a new issue,706431.
,
Jul 4
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ddorwin@chromium.org
, Mar 21 2017Labels: M58