Created attachment 282397 [details] [diff] [review] 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 ;)
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.
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: review?(roc) → review+
Attachment #282397 - Flags: approval1.9?
Attachment #282397 - Flags: approval1.9? → approval1.9+
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.