397641 - AsyncScrollPortEvent posted even if overflow/underflow event won't be dispatched

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

Attachment: possible patch

Currently nsGfxScrollFrameInner::PostOverflowEvent creates new AsyncScrollPortEvent even if overflow/underflow event won't be dispatched in
nsGfxScrollFrameInner::FireScrollPortEvent().
When handling AsyncScrollPortEvents, there is also a FlushPendingNotifications(Flush_Layout) in nsGfxScrollFrameInner::AsyncScrollPortEvent::Run, that is causing lots of
flushing during tdhtml.
(See also https://bugzilla.mozilla.org/show_bug.cgi?id=365477#c16)

I think copying the "is-overflow/underflow-event-needed" check from
FireScrollPortEvent() might make sense. Those checks used to be there
until Bug 365477 moved them to be only in FireScrollPortEvent().

Also, to handle HTML and XUL similarly, better to PostOverflowEvent() right
before returning from Layout()/Reflow(). Makes code easier to follow, and
reflow must now have happened before calling PostOverflowEvent.

Currently when running tdhtml (iterations = 5),  ~5700 AsyncScrollPortEvents
are created, with the patch that drops to ~20.
I think there is only one page in tdhtml which has scrollbars (at least when
running the test on this machine).
With tp2 where pages are larger (so that overflow really happens quite often),
the change isn't as big. w/o patch ~2000, w patch ~400.

Mats, do you think there is something the patch might break? At least I couldn't
find any problems using the testcases in scrolling related bugs.
And feel free to r+sr ;)

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #0)
> Currently when running tdhtml (iterations = 5),  ~5700 AsyncScrollPortEvents
> are created

And pretty much all of those call flush. Total flush count during tdhtml is 
~14600, so if the patch is any good, there would be significantly less flushing.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #1)
>Total flush count during tdhtml is  ~14600, 

That is, calls to nsIPresShell::FlushPendingNotifications.
PresShell::DoFlushPendingNotifications is called a lot more often.

Comment 3

[Mats Palmgren (inactive)]

Comment on attachment 282397 [details] [diff] [review]
possible patch

Good catch.  This looks good to me, r+sr=mats but it would be good
if roc@ have time for a quick look as well.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Looks good, but is there a way to share that checking code?

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

The duplicated code isn't long and nsGfxScrollFrameInner::FireScrollPortEvent
uses some of the variables later in the method, so making a common function
to check whether !vertChanged && !horizChanged wouldn't be that useful.