Scrolling regression on IP Board forums




6 years ago
6 years ago


(Reporter: timbugzilla, Assigned: roc)


Windows 7
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(4 attachments)



6 years ago
Since dlbi has landed (i.e. today's nightly moz central build) scrolling on IP Board webforum sites has been slow with lots of lag (very much not smooth).

An example:


6 years ago
Blocks: 539356

Comment 1

6 years ago
This has been reproduced by posters on the Mozillazine forum. 

The Verge's homepage also seems to be affected:
Assignee: nobody → roc
Created attachment 638262 [details]

Scrolling this testcase shows the problem.

We create a temporary layer manager for the <div> with opacity. Its layer tree has a ContainerLayer containing a ThebesLayer. As we scroll, the transform on the ThebesLayer changes because the offset to the active-scrolled-root is changing. In FrameLayerBuilder::AddThebesDisplayItem, this makes props->ComputeDifferences return the whole <div> area as different.

Comment 3

6 years ago
This seems to only be noticeable on the forum index page with D2D active.
Dunno if this is related, but scrolling in Timezone drop down menu on
is also laggy
Assignee: roc → nobody
Component: General → Layout
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → layout
I'm thinking of fixing this by adding a translation parameter to LayerProperties::ComputeDifferences, so that it computes differences after translating the stored layer tree by the given translation.

Comment 6

6 years ago
This is another page that is a good example of scrolling lag/slowness:
Created attachment 638927 [details] [diff] [review]
work-in-progress fix

This fixes my testcase pretty well. However, if I press "End" to scroll to the end, "Home" to scroll to the top, then "down" to smooth-scroll down one line, the Hello div gets invalidated once. That shouldn't happen, so something's not quite right here.

Also, before landing this I'd want to test scrolling of non-actively-transformed elements with various different kinds of transforms.
Assignee: nobody → roc

Comment 8

6 years ago
Scrolling still lags and is slow with the inbound PGO build built from the following changeset (includes all the DLBI stuff):
I don't see (abnormally) slow scrolling on any of the pages here in linux-x64/basic or win7/d3d10., can you let us know the exact steps you're following to see slow scrolling?

Comment 10

6 years ago
On I can reproduce it by holding down the down arrow key. There's a big lag/stutter before normal scrolling speeds return.

I see this on win7 and win8 with D2D and D3D10. I am not seeing it with D2D disabled.

Comment 11

6 years ago
Created attachment 666288 [details]
about:support output on fresh/default profile

Comment 12

6 years ago
I've uploaded a profile taken during the jerky scrolling here:

(taken with a fresh/default profile)

about:support output is attached as a text file.

Comment 13

6 years ago
Last bit of forgotten info ;-) Build was moz-central PGO win32 from this change set:

Comment 14

6 years ago
Created attachment 666290 [details]
sample html

Slow scrolling with HWA, thanks for all the data! :)  I'm not able to reproduce slow scrolling on that page, but it might just be that the machine I'm testing on is too fast.

Your profile shows us spending a huge amount of time in NtGdiDdDDIDestroyAllocation().  I don't know what the function is, but this is very surprising.  Bas, any ideas?

Alice0775 White, I see *terrible* scrolling performance on your testcase with win7/d3d10.  Scrolling performance is not (abnormally) slow in linux-x64/basic.

We seem to be layerizing all the <span>s in that test and invalidating them on every scroll.  That's not expected.  We're probably hitting some d2d or d3d10 slow path, or enqueuing too much work for the GPU.
Scrolling performance is much worse in linux-x64/GL than linux-x64/basic, but it's still nowhere near as bad as win7/d3d10.
Ah, this was already analyzed in comment 2.

roc's WIP is entirely bitrotted so I don't know if it still mostly fixes this.
Matt tells me that he integrated roc's patch into his dlbi re-landing, so new regressions from this should be filed as new bugs.

(And man, really hurts, please file! :) )
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME

Comment 19

6 years ago
As I'm still seeing this with the win32 PGO build from the a680fd777c3b change-set [1], I'll file a new bug with the same info and mark it blocking the dlbi bug.

Did we ever find out what NtGdiDdDDIDestroyAllocation was and how to reduce it? I got another profile from a user seeing bad performance showing this function and this is now the top google it for it.
(In reply to Benoit Girard (:BenWa) from comment #21)
> Did we ever find out what NtGdiDdDDIDestroyAllocation was and how to reduce
> it? I got another profile from a user seeing bad performance showing this
> function and this is now the top google it for it.

It's more or less texture destruction. It shows up higher than I'd expect though, one obvious way to reduce it is by doing our own texture pool and light-weight allocator for ThebesLayers. Usually it's ~ThebesLayer triggering this function.

I still wonder if there's any flag we can use to make this less heavy on our textures though.
You need to log in before you can comment on or make changes to this bug.