1429363 - APZ hit testing is janky on http://perf.rust-lang.org/ during load

Status: RESOLVED WORKSFORME

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

Description

[Markus Stange [:mstange]]

Scrolling up and down on http://perf.rust-lang.org/ while that page is loading, with gfx.webrender.hit-test and blob-images enabled, is rather unresponsive.

It looks like hit testing on the parent main thread is somehow blocked on blob-image rasterization.

Comment 1

[Milan Sreckovic [:milan] (needinfo for best results)]

Let's test this on reference hardware, see what it looks like.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Here's a profile that Markus made that shows the problem: https://perfht.ml/2mIGWsl

The main thread is blocked in wr_api_hit_test because the WRRenderBackend thread (which should be servicing the hit-test request) is busy in an update_document call. I believe this will be resolved once the transaction stuff is further along, because the update_document will get bumped to a worker thread and leave the WRRenderBackend more free.

Comment 3

[Markus Stange [:mstange]]

Even after async-blob landed, hit testing can still block on rasterization: https://perfht.ml/2uUmN5L
I took this profile with https://static.mozilla.com/moco/en-US/images/mozilla_eoy_2013_EN.svg open in background tab. I clicked on the background tab and tried to keep scrolling the foreground tab until the clicked tab rendered. It works some of the time but freezes the browser other times.

Comment 4

[Aria Beingessner [:Gankra]]

This page seems to be pretty egregious even with vanilla gecko (though a bit better), is it enough worse for us to block release on?

Comment 5

[Maire Reavy [:mreavy]]

Hi Alexis -- How often are other APZ cases going to hit this?  And do you have a sense of what the impact will be?

Comment 6

[Markus Stange [:mstange]]

I actually can't reproduce the original problem any more: That is, the main thread of the parent process being blocked on blob rasterization. That was the piece that I think would have been worth blocking on.

Here's a current profile: https://perfht.ml/2NyelEL
It shows the main thread of the parent process being perfectly responsive. It blocks on the render backend thread for short amounts of time, but that thread is not blocked on blob rasterization in this profile.

And here's a profile of scrolling https://static.mozilla.com/moco/en-US/images/mozilla_eoy_2013_EN.svg , which has more expensive blob rasterization: https://perfht.ml/2NwsPVH
The render backend never seems to block on blob rasterization here either.

So I'm going to resolve this bug as WFM.