Closed Bug 1251612 Opened 9 years ago Closed 4 years ago

Convert test_smoothness.html to a mochitest-browser-chrome or a mochitest-plain

Categories

(Core :: Panning and Zooming, defect, P3)

Product:
Core
Component:
Panning and Zooming
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
81 Branch
Tracking Flags:
Tracking Status
firefox81 --- fixed

People

(Reporter: kats, Assigned: kats)

References

(Blocks 1 open bug)

Details

(Whiteboard: [gfx-noted])

Attachments

(3 files)

Bug 1251612 - Support the GetFrameUniformity API in content processes. r?botond
(deleted), text/x-phabricator-request
Details
Bug 1251612 - Make test_smoothness a plain mochitest. r?botond
(deleted), text/x-phabricator-request
Details
Bug 1251612 - Sanitize layer transforms before computing stddev. r?botond
(deleted), text/x-phabricator-request
Details
test_smoothness.html tests APZ scrolling smoothness. However this test has never run in automation because the conditions in chrome.ini require e10s for this test. Chrome mochitests have never actually run in e10s, nor will they ever run in e10s because in a chrome mochitest everything lives in the parent process anyway (so there's no difference between e10s and non-e10s). We should rewrite this test as a mochitest-browser-chrome if we want to have the "get frame uniformity" piece live in the parent process while the "scroll page" piece lives in the child process. Alternatively we could add some plumbing to get the frame uniformity values down into the content process (i.e. implement [1]) and then run it as a mochitest-plain. I think the browser-chrome option is probably better. [1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/CompositorParent.cpp?rev=68295c584858#1929

I don't know why I said the browser-chrome option was better. Making it a mochitest-plain seems simpler though, so I'll do that. I'm not sure it needs to be run by default in CI because it's going to be hard to get consistent results. However this test might be a thing to run locally to validate changes that fiddle with smoothness (e.g. bug 1641070).

Assignee: nobody → kats
Blocks: 1641070

I got it running as a mochitest-plain locally (macOS opt build) and I'm getting large values (~10) which is causing the test to fail. According to the comments Mason left the values should be lower, so I guess we have regressed smoothness. :(

This moves the IPC mechanism from PCompositorBridge to PLayerTransaction/
PWebRenderBridge, so that it can be used by content processes like the other
test APIs. It still only produces actual data for the layers backend; for
WR it will just return empty datasets.

Also modernize it a tiny bit. This also adjusts the conditions under which
the test is run, and keeps it disabled on CI for now since it's not clear
this will provide value from being run in CI at the moment (fails a lot).

Depends on D86016

Pushed by kgupta@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/aaa270392a4a Support the GetFrameUniformity API in content processes. r=botond,froydnj https://hg.mozilla.org/integration/autoland/rev/30b9cdd0691b Make test_smoothness a plain mochitest. r=botond https://hg.mozilla.org/integration/autoland/rev/5490ac142668 Sanitize layer transforms before computing stddev. r=botond
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: