Closed
Bug 43121
Opened 24 years ago
Closed 23 years ago
pull XUL content model out of rdf.dll
Categories
(Core :: XUL, defect, P3)
Core
XUL
Tracking
()
RESOLVED
FIXED
mozilla0.9
People
(Reporter: waterson, Assigned: waterson)
References
Details
(Keywords: arch)
Attachments
(2 files)
258.11 KB,
application/octet-stream
|
Details | |
11.76 KB,
patch
|
Details | Diff | Splinter Review |
An issue that has been coming up more frequently with respect to embedding has been proper factoring of our DLLs. A couple of us were talking today and came up with some ideas to better factor one of our largest offenders, librdf.so. Summary I'd like to take the contents of rdf/content/src and move them to layout/xul/content/src, layout/xul/content/document, and dom. I'll be breaking things along the same lines that HTML and XML content do (./document gets content sink and document files; ./content gets content node files; ./dom gets vidur-IDL and stubs). Some of the files that move to DOM will live there only until hyatt and ben can get rid of the JS glue, replacing it with its XBL equivalents; others will become permanent residents (nsJSXULElement.cpp and nsJSXULDocument.cpp, for example). These could theoretically be controlled by "#ifdef INCLUDE_XUL". The files that move to layout/xul will be built into a standalone DLL, libxul.so, which will have no link-time dependencies on anything else in the layout directory. Background librdf.so is a 1Mb DLL (optimized, Linux) that holds both the XUL content model (about 80% of its bulk) and some miscellany used to parse RDF/XML and maintain in-memory datasources. libchrome.so is a 150Kb DLL that uses librdf.so to properly indirect "chrome:" URLs. Necko, Gecko, and others are pull libchrome.so and librdf.so into their dependency graph primarily because of reliance on "chrome:" URLs (e.g., to load string bundles, to provide skin-switching capabilites for XUL). - The "chrome registry" is an RDF/XML file which stores the indirection information - The chrome registry is used to provide propery indirection to the currently selected locale. To date, no embedders require this functionality. Strictly speaking, XUL can run *without* RDF and the chrome registry with only modifications to the XBL and CSS files it uses. (Replacing "chrome:" URLs with "resource:" URLs, for example.) The XPFE team is currently working to break link-time dependencies on nsContainerFrame, and eventually plan to be able to Rationale Going forward, we need to make a decision with respect to embedding. To include XUL, or not to include XUL? XUL makes many embedding issues extremely straightforward: it provides dialogs, tooltips, context menus, focus management, command updating, and someday may even provide the widget set itself via XBL. This flexibility currently comes with a fairly large footprint cost: on Linux, the XUL content frames account for 15% of libraptorhtml.so's size (about 1Mb out of 7Mb), and 80% of librdf.so's size (800Kb out of 1Mb). While it may make sense in the long run to re-use XUL and XBL within HTML, in the short term, having a plan to factor XUL into its own module seems to make the most sense. This separates RDF/XML and chrome resolution from core XUL content, reducing XUL content's payload by about 30%; RDF/XML and chrome would live in their own 200Kb and 150Kb libraries, saving a 350Kb code footprint. Future If nsCSSFrameConstructor could dispatch on namespace, and with additional effort to remove the XUL frames' depenency on nsContainerFrame, XUL frames could theoretically live in their own DLL. This would reduce the core HTML layout engine's size by about 15%. In theory, this would allow Gecko to be embedded without XUL; however, it would require us (well, jud and rpotts) to design solutions for at least the following problems: 1. maintaining focus state 2. handling keybindings (e.g., PgUp PgDn) 3. event propogation to the HTML container 4. tooltips, context menus, dialogs, ... (Hyatt can discuss these better; I'm sketching...) Alternatively, XUL and XBL could form the basis for the existing form controls. Right now, the bulk (about 36%) of libraptorhtml.so comes from the HTML content elements, many of which are form controls. Using XBL, many of these could be replaced with JS implementations which have negligible footprint. In any case, factoring out XUL's content elements and co-locating in the source tree them with the XUL frames seems to make sense, even if the content nodes continue to live in their own DLL.
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Assignee | ||
Comment 1•24 years ago
|
||
dougt said he'd belly up to the task because this is important for embedding. Here are the things that need to happen: 1. Move DOM-IDL files in rdf/content/public/idl to dom/public/idl/xul, generate headers into dom/public/xul, generate source into dom/src/xul, link with JDDOM.DLL (possibly #ifdef INCLUDE_XUL, if you can). 2. Move remaining files from rdf/content/[src|public] to layout/xul/content/[src|public]. These files should be linked into a separate XUL.DLL, *not* GKHTML.DLL. (hyatt: please expand if there are files that are exceptions to this rule and should be made part of the main layout build, e.g., nsControllerCommandManager.cpp, aka nsAnalMicroManagingBeuraucrat.cpp) 3. There are a couple of XPIDL interfaces in rdf/base/idl that should be moved into layout (xulstudbs.idl, nsIXULSortService.idl, nsIXULTemplateBuilder.idl, nsIController.idl, nsIControllers.idl, and that saucy dominatrix nsIControllerCommand.idl). 4. Get leaf to help you copy the ,v files so that we can keep CVS history! hyatt: is there anything I forgot?
Assignee: waterson → dougt
Status: ASSIGNED → NEW
Comment 2•24 years ago
|
||
never got around to this. Per a conversation with hyatt a few weeks ago, I am reassigning to him.
Assignee: dougt → hyatt
Comment 3•24 years ago
|
||
->waterson cuz hyatt sez yer already workin on it
Assignee: hyatt → waterson
Assignee | ||
Comment 4•24 years ago
|
||
I have this working on Windows now. Here is a summary of what I've done. - Moved the following files: * XUL DOM glue now lives in the JS-DOM DLL. rdf/content/public/idl/XULCommandDispatcher.idl XULDocument.idl XULElement.idl XULTreeElement.idl --> dom/public/idl/xul rdf/content/public/nsIDOM*.h --> dom/public/xul rdf/content/src/nsJSDOM*.cpp --> dom/src/xul * Created a `layout/xul/document' directory. rdf/content/idl/nsIController.idl nsIControllers.idl nsIControllersCommand.idl rdf/content/public/nsIXULContentSink.h nsIXULDocument.h nsIXULPrototypeCache.h nsIXULPrototypeDocument.h --> layout/xul/document/public rdf/conteont/src/nsElementMap.cpp nsElementMap.h nsForwardReference.h nsXULCommandDispatcher.cpp nsXULCommandDispatcher.h nsXULContentSink.cpp nsXULControllers.cpp nsXULControllers.h nsXULDocument.cpp nsXULDocument.h nsXULPrototypeCache.cpp nsXULPrototypeDocument.cpp --> layout/xul/document/src * Added to the `layout/xul/content' directory rdf/content/public/nsIXULContent.h nsIXULPopupListener.h --> layout/xul/content/public rdf/content/src/nsIRDFNodeList.h nsIXULTreeContent.h nsRDFDOMNodeList.cpp nsRDFDOMNodeList.h nsXULAtoms.cpp nsXULAtoms.h nsXULAtoms.inc nsXULAttributeValue.cpp nsXULAttributeValue.h nsXULAttributes.cpp nsXULAttributes.h nsXULElement.cpp nsXULElement.h nsXULPopupListener.cpp nsXULTreeElement.cpp nsXULTreeElement.h --> layout/xul/content/src * Created a `layout/xul/templates' directory. rdf/content/idl/nsIXULSortService.idl nsIXULTemplateBuilder.idl rdf/content/src/nsIRDFContentModelBuilder.h --> layout/xul/templates/public rdf/content/src/nsRDFSort.h nsRuleNetwork.cpp nsRuleNetwork.h nsXULContentUtils.cpp nsXULContentUtils.h nsXULSortService.cpp nsXULTemplateBuilder.cpp --> layout/xul/templates/src - Re-ordered RDF to earlier in the build (well before layout). RDF no longer needs to depend on JS, GFX, or DOM, but layout needs to be built after RDF because XUL has some IDL that talks about RDF interfaces (the template builder stuff, which for now is going in the layout DLL because it's pretty tightly tied up with the content model stuff.) - Turned off building `rdf/tests/domds': it needs to find a better place to live than in the RDF directory. - Renamed contract-IDs from `@mozilla/rdf/xul-*' to `@mozilla/xul/xul-*' (e.g., `@mozilla/rdf/xul-prototype-cache;1' became `@mozilla/xul/xul-prototype-cache;1'). - Got rid of `nsIXULContentUtils' interface. This was only being used outside the `layout/xul' directory to determine if XUL prototype caching was `on' (e.g., nsCSSLoader, nsXBLService). I just added a method to the prototype cache that allows you to ask if it's on or not. - Consolidated some of the common content sink routines into `layout/base/src/nsParserUtils.[h|cpp]', and fixed the XML and HTML content sinks to use these. (The XUL content sink was previously using `nsRDFParserUtils', so I needed to find a replacement for those utility routines.)
Status: NEW → ASSIGNED
Target Milestone: M18 → mozilla0.8
Assignee | ||
Comment 5•24 years ago
|
||
Slipping to 0.9; gated on heikki's work for 43142. Also, I don't know why this bug depends on 39965: it doesn't.
Depends on: 43142
Target Milestone: mozilla0.8 → mozilla0.9
Assignee | ||
Comment 6•23 years ago
|
||
Assignee | ||
Comment 7•23 years ago
|
||
A million apologies for attaching gzip'd diffs, but the uncompressed version was too big for bugzilla. Looking for some r= and sr= love here; hoping to land this tomorrow after dougt's stuff winds up...
Comment 8•23 years ago
|
||
rs/sr=hyatt
Comment 9•23 years ago
|
||
r=jst
Comment 10•23 years ago
|
||
rs=brendan@mozilla.org Our widdle baby's all growds up! /be
Assignee | ||
Comment 11•23 years ago
|
||
Assignee | ||
Comment 12•23 years ago
|
||
Done, sorta sloppy. Need to take a second pass through to make #ifdef's work right and stuff...
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•