IsSmoothScroll depends on the exact values of dom::ScrollBehavior, which is defined in Window.webidl. Therefore, to define those values for IsSmoothScroll, we would need to include WindowBinding.h. That file, however, drags in many different dependencies to many different places (e.g. IPDL generated protocols), which is undesirable. To work around this, define the function out-of-line so that only ScrollbarStyles.cpp needs to include WindowBinding.h. Doing this cuts down files that depend on WindowBinding.h by ~25%.
Created attachment 8678299 [details] [diff] [review] out-of-line ScrollbarStyles::IsSmoothScroll
Attachment #8678299 - Flags: review?(bzbarsky)
Hrm. Why does WindowBinding.h drag in so much? Our general goal for the binding _headers_ has been to drag in as little as we can manage....
Comment on attachment 8678299 [details] [diff] [review] out-of-line ScrollbarStyles::IsSmoothScroll In any case, r=me
Attachment #8678299 - Flags: review?(bzbarsky) → review+
(In reply to Boris Zbarsky [:bz] from comment #2) > Hrm. Why does WindowBinding.h drag in so much? Our general goal for the > binding _headers_ has been to drag in as little as we can manage.... Looks like WindowBinding.h drags in: ErrorResult.h -> nscore.h -> all the XPCOM string stuff mozilla/dom/BindingDeclarations.h -> mozilla/dom/CallbackObject.h -> nsContentUtils.h -> gfx data structures -> stdlib stream junk CycleCollectedJSRuntime.h also drags in a raft of stuff, mostly due to <queue>. Some of this stuff is not avoidable, I suppose, but it adds up to ~4MB text for the compiler to process, from one header...
> ErrorResult.h -> nscore.h -> all the XPCOM string stuff Sure, but in practice any file including *Binding.h is likely to pull in all the XPCOM string stuff anyway, right? I guess the preprocessor still has to deal with snipping out the extra copies.... > mozilla/dom/BindingDeclarations.h -> mozilla/dom/CallbackObject.h -> nsContentUtils.h I don't see BindingDeclarations.h including CallbackObject.h. Which is good, because I was explicitly trying to keep nsContentUtils.h out of BindingDeclarations.h. I assume the real path is CallbackFunction.h -> CallbackObject.h -> nsContentUtils.h. And WindowBinding.h does need to include CallbackFunction.h to do its callback function declarations. Now the better question is whether CallbackObject.h needs to include nsContentUtils.h. It used to for nsCxPusher, but it doesn't do that anymore (and cxpusher got moved to ScriptSettings.h anyway). So maybe we could nix it.
You need to log in before you can comment on or make changes to this bug.