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




11 years ago
11 years ago


(Reporter: smaug, Assigned: smaug)


({perf, regression})

perf, regression

Firefox Tracking Flags

(Not tracked)



(1 attachment)

Created attachment 282397 [details] [diff] [review]
possible patch

Currently nsGfxScrollFrameInner::PostOverflowEvent creates new AsyncScrollPortEvent even if overflow/underflow event won't be dispatched in
When handling AsyncScrollPortEvents, there is also a FlushPendingNotifications(Flush_Layout) in nsGfxScrollFrameInner::AsyncScrollPortEvent::Run, that is causing lots of
flushing during tdhtml.
(See also

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 ;)
Attachment #282397 - Flags: review?(mats.palmgren)
(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.
(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.

Attachment #282397 - Flags: review?(mats.palmgren) → review?(roc)
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.
Attachment #282397 - Flags: superreview+
Attachment #282397 - Flags: review+
Blocks: 365477
Keywords: perf, regression
Looks good, but is there a way to share that checking code?
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.
Attachment #282397 - Flags: approval1.9?
Assignee: nobody → Olli.Pettay
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.