1768766 - Parent Process jank on moving mouse inside https://codepen.io/khanhtranngoccva/pen/vYdKYpE (Was: Jank when hovering cursor over search result items on https://codepen.io/search/pens?q=3d+css&order=created_desc)

Status: NEW

(Core :: Graphics: WebRender, defect, P3)

Description

[Gregory Pappas [:gregp]]

Steps to reproduce:

1. Navigate to https://codepen.io/search/pens?q=3d+css&order=created_desc
2. Hover cursor over search result item

Actual results: Jank

Expected results: Less jank

https://share.firefox.dev/3kWCeFd

Comment 1

[Mayank Bansal]

The actual jank is from this demo : https://codepen.io/khanhtranngoccva/pen/vYdKYpE
Profile : https://share.firefox.dev/3yq0JCB

Lots of jank on the parent process in APZ?

Comment 2

[Florian Quèze [:florian]]

The profile from comment 0 is on Linux, and there's a lot of CPU used in the content process main thread, mostly in painting code: https://share.firefox.dev/3w352C6 There's a WRRenderBackend thread on the parent process that also keeps a CPU core quite busy: https://share.firefox.dev/38lfJqG
Emilio, anything there that looks like it should be optimized? (feel free to forward the needinfo)

The profile from comment 1 is on Windows, and very different. There is very little CPU use. The parent process main thread is blocked on PAPZInputBridge::Msg_ReceiveMouseInputEvent sync IPCs to the GPU process, that is blocked waiting for a lock at https://searchfox.org/mozilla-central/rev/88792eff309001778cb2431f2a0ed92f8f3c258a/gfx/layers/apz/src/APZCTreeManager.cpp#1444 This is probably a great profile to understand bug 1677509.

Comment 3

[Mayank Bansal]

This is a weird demo.. Without moving mouse, the GPU process keeps on using 1 full CPU core. However, the GPU use itself is ~10% only.
Profile : https://share.firefox.dev/3L8pnu2

If I move the mouse pointer inside the demo such that the demo also animates, the profile is different : https://share.firefox.dev/3Nb5OCV

Comment 4

[Florian Quèze [:florian]]

On Mac where there's no GPU process, we don't get blocked on sync IPC, but the parent process main thread also gets blocked waiting on the mutex in GetTargetAPZC: https://share.firefox.dev/39U60In

Comment 5

[Emilio Cobos Álvarez (:emilio)]

(In reply to Florian Quèze [:florian] from comment #2)

The profile from comment 0 is on Linux, and there's a lot of CPU used in the content process main thread, mostly in painting code: https://share.firefox.dev/3w352C6 There's a WRRenderBackend thread on the parent process that also keeps a CPU core quite busy: https://share.firefox.dev/38lfJqG
Emilio, anything there that looks like it should be optimized? (feel free to forward the needinfo)

Most of the time is spent in this UntransformRect call or the one right after. I'm not familiar with transform pre-rendering, etc. Maybe Boris / Miko knows why we're not taking any of the earlier branches.

It seems at the very least we could trivially avoid computing the transform matrix twice (once for each UntransformRect call).

Comment 6

[Gregory Pappas [:gregp]]

Profile after bug 1768846
https://share.firefox.dev/3FM24W0

Comment 7

[Miko Mynttinen]

The display list build times are slow because RDL does not play nice with CSS 3D transforms. Other notable thing in the profile is that WR renderer backend seems very busy building a BSP tree, spending up to 1000ms on it.

Comment 8

[Boris Chiou [:boris]]

We avoid the compute transform matrix twice since Bug 1768846. Also, I guess for now, the main root cause has been mentioned in comment 7, so clear my ni.