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: http://www.daimenhutchison.com/rugby/index.php/index
This has been reproduced by posters on the Mozillazine forum. The Verge's homepage also seems to be affected: http://www.theverge.com/
6 years ago
Depends on: 770001
6 years ago
Assignee: nobody → roc
Created attachment 638262 [details] testcase 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.
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 https://lavabit.com/apps/webmail/src/login.php is also laggy
Assignee: roc → nobody
Status: UNCONFIRMED → NEW
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.
This is another page that is a good example of scrolling lag/slowness: http://boingboing.net/2012/07/03/cisco-locks-customers-out-of-t.html#disqus_thread
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
Scrolling still lags and is slow with the inbound PGO build built from the following changeset (includes all the DLBI stuff): http://hg.mozilla.org/integration/mozilla-inbound/rev/7d4e659d6fbf
I don't see (abnormally) slow scrolling on any of the pages here in linux-x64/basic or win7/d3d10. email@example.com, can you let us know the exact steps you're following to see slow scrolling?
On http://www.daimenhutchison.com/rugby/index.php/index 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.
I've uploaded a profile taken during the jerky scrolling here: http://people.mozilla.com/~bgirard/cleopatra/?report=d447825ef05bdba0abed3e605da1f275d9ca4c27 (taken with a fresh/default profile) about:support output is attached as a text file.
Last bit of forgotten info ;-) Build was moz-central PGO win32 from this change set: http://hg.mozilla.org/mozilla-central/rev/85f561c755f6
firstname.lastname@example.org, 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, https://bugzilla.mozilla.org/attachment.cgi?id=666290 really hurts, please file! :) )
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
As I'm still seeing this with the win32 PGO build from the a680fd777c3b change-set , I'll file a new bug with the same info and mark it blocking the dlbi bug.  http://hg.mozilla.org/mozilla-central/rev/a680fd777c3b
Sounds good, thanks.
No longer blocks: 770524
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.