Closed Bug 1705925 Opened 4 years ago Closed 3 years ago

(sw-wr) Stuttery scrolling on https://www.foxitsoftware.com/pdf-reader/

Categories

(Core :: Graphics: WebRender, enhancement)

enhancement

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mayankleoboy1, Assigned: gw)

References

(Blocks 1 open bug)

Details

enable sw-wr
Go to https://www.foxitsoftware.com/pdf-reader/
Scroll on the page, specially the top of the page with the orange background

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

Blocks: sw-wr-perf

Matt, looks like a lot of time spent in UnmapTile in D3D11 compositor...

Flags: needinfo?(matt.woodrow)

Indeed there is a lot of time spent there, but as is common with Mayank's profiles, most of the time there appears to just be blocking within the kernel (NtQueryLicenseValue).

My understanding is that this mostly means that other work is slowing down the kernel and it's not necessarily this call that's actually the problem. Nothing else really stands out from the profile though, and than that it's doing a lot of work for advanced blend modes.

Let's chat about this more during the sw-wr meeting tomorrow!

Flags: needinfo?(matt.woodrow)

Looks like picture caching isn't working well for this and we're drawing more than we might need to be. Adding ni?gw to dig into this a bit more.

Flags: needinfo?(gwatson)

I can see what's causing the constant invalidation.

The page content contains a mix-blend container right at the start of the content display list, because the fixed position background image has overlay mix-blend-mode set. In combination with the scrolling content and other fixed position elements, WR currently places all of this content in the same slice to ensure the mix-blend-mode works correctly.

I can think of a couple of possible solutions to this, but I will need to investigate a bit more. It's also possible that the way the current blend container APIs work in WR is making this seem harder than it needs to be.

Assignee: nobody → gwatson
Flags: needinfo?(gwatson)

It seems like this is resolved now from a quick test of the page, either by some recent WR work or by the page content itself changing. Does this seem fine in nightly for you?

Flags: needinfo?(mayankleoboy1)

Here is an archive of the page from the time of reporting.

Profile from the original page (from webarchive): https://share.firefox.dev/35XJzA6
Profile from the current version of the page: https://share.firefox.dev/3CByjpn

Edit: it is definitely improved. Lets close this bug for now, and file new one if needed.

Flags: needinfo?(mayankleoboy1) → needinfo?(gwatson)
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(gwatson)
Resolution: --- → FIXED

(In reply to Glenn Watson [:gw] from comment #5)

It seems like this is resolved now from a quick test of the page, either by some recent WR work or by the page content itself changing. Does this seem fine in nightly for you?

Shouldn't the resolution here be WORKSFORME? It is normally FIXED only if there is a patch in the bug or a demonstrated connection to another bug report that has a patch.

Flags: needinfo?(mayankleoboy1)
Flags: needinfo?(mayankleoboy1)
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.