Closed Bug 770061 Opened 12 years ago Closed 12 years ago

Scrolling regression on IP Board forums

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: timbugzilla, Assigned: roc)

References

(
URL
)

Details

Attachments

(4 files)

testcase
101 bytes, text/html
Details
work-in-progress fix
19.15 KB, patch
Details | Diff | Splinter Review
about:support output on fresh/default profile
3.10 KB, text/plain
Details
sample html
16.60 KB, text/html
Details 
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
Blocks: dlbi
This has been reproduced by posters on the Mozillazine forum. 

The Verge's homepage also seems to be affected:

http://www.theverge.com/
Assignee: nobody → roc
Attached file 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.
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
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.

timbugzilla@gmail.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
Attached file sample html — 
Slow scrolling with HWA
timbugzilla@gmail.com, 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
Closed: 12 years ago
Resolution: --- → WORKSFORME
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.




[1] http://hg.mozilla.org/mozilla-central/rev/a680fd777c3b
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.

Attachment

General

Creator:
Created:
Updated:
Size: