out-of-line ScrollbarStyles::IsSmoothScroll

NEW
Assigned to

Status

()

3 years ago
3 years ago

People

(Reporter: froydnj, Assigned: froydnj)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

3 years ago
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%.
(Assignee)

Comment 1

3 years ago
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+
(Assignee)

Comment 4

3 years ago
(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.