We mark constructors as static in the parser because they are. This
allows us to just use the isStatic() for the IDLMember to mark our
declarations static.
To generate an example interface implementation, just "make
interfacename-example" in $objdir/dom/bindings. This will place files
called interfacename-example.h and interfacename-example.cpp in that
directory. For example, "make XMLHttpRequest-example" will get you
$objdir/dom/bindings/XMLHttpRequest-example.h and
$objdir/dom/bindings/XMLHttpRequest-example.cpp.
Attribute getters currently default to const methods, while setters
and operations default to non-const methods.
--HG--
rename : dom/bindings/BindingGen.py => dom/bindings/ExampleGen.py
This patch enables sharing of an nsAttrValue's MiscContainer between nodes for style rules. MiscContainers of type eCSSStyleRule are now refcounted (with some clever struct packing to ensure that the amount of memory allocated for MiscContainer remains unchanged on 32 and 64 bit). This infrastructure can be used to share most MiscContainer types in the future if we find advantages to sharing other types than just eCSSStyleRuley. A cache mapping strings to MiscContainers has been added to nsHTMLCSSStyleSheet. MiscContainers can be shared between nsAttrValues when one nsAttrValue is SetTo another nsAttrValue or when there is a cache hit in this cache. This patch also adds the ability to tell a style rule that it belongs to an nsHTMLCSSStyleSheet, with appropriate accessor functions to separate that from the existing case of belonging to an nsCSSStyleSheet.
The primary use case is to reduce memory use for pages that have lots of inline style attributes with the same value. This can happen easily with large pages that are automatically generated. An (admittedly pathological) testcase in Bug 686975 sees over 250 MB of memory savings with this change. Reusing the same MiscContainer for multiple nodes saves the overhead of maintaining separate copies of the string containing the serialized value of the style attribute and of creating separate style rules for each node. Eliminating duplicate style rules enables further savings in layout through style context sharing. The testcase sees the amount of memory used by style contexts go from over 250 MB to 10 KB.
Because the cache is based on the text value of the style attribute, it will not handle attributes that have different text values but are parsed into identical style rules. We also do not attempt to share MiscContainers when the node's base URI differs from the document URI. The effect of these limitations is expected to be low.
Another implementation option would be to put all the dictionaries in a single
file and have a static global set of ids which works across all dictionaries
and is initialized once at startup or so. That would also handle cross-file
dictionary inheritance better.
One problem that remains is the fake descriptor business. At the moment this
does not allow interface types inside dictionaries. We could probably work
around this by either refactoring code to make it possible to get the declType
independently of the actual conversion template (whether because it lives in a
separate function or because the conversion template generator knows to just
return an empty string when the fake descriptor provirder is passed) or by
figuring out a way to pass an actual descriptor provider to dictionary codegen.
ErrorResult is in a separate header file so it can be included from all over the
place without having to pull in mozilla/dom/Utils.h and all the xpconnect gunk
that needs.
ErrorResult is in a separate header file so it can be included from all over the
place without having to pull in mozilla/dom/Utils.h and all the xpconnect gunk
that needs.
In the new setup, all per-interface DOM binding files are exported into
mozilla/dom. General files not specific to an interface are also exported into
mozilla/dom.
In terms of namespaces, most things now live in mozilla::dom. Each interface
Foo that has generated code has a mozilla::dom::FooBinding namespace for said
generated code (and possibly a mozilla::bindings::FooBinding_workers if there's
separate codegen for workers).
IDL enums are a bit weird: since the name of the enum and the names of its
entries all end up in the same namespace, we still generate a C++ namespace
with the name of the IDL enum type with "Values" appended to it, with a
::valuelist inside for the actual C++ enum. We then typedef
EnumFooValues::valuelist to EnumFoo. That makes it a bit more difficult to
refer to the values, but means that values from different enums don't collide
with each other.
The enums with the proto and constructor IDs in them now live under the
mozilla::dom::prototypes and mozilla::dom::constructors namespaces respectively.
Again, this lets us deal sanely with the whole "enum value names are flattened
into the namespace the enum is in" deal.
The main benefit of this setup (and the reason "Binding" got appended to the
per-interface namespaces) is that this way "using mozilla::dom" should Just
Work for consumers and still allow C++ code to sanely use the IDL interface
names for concrete classes, which is fairly desirable.
--HG--
rename : dom/bindings/Utils.cpp => dom/bindings/BindingUtils.cpp
rename : dom/bindings/Utils.h => dom/bindings/BindingUtils.h
