151
edits
Mozilla 2: Difference between revisions
m
markup improvment, no content change
m (markup improvment, no content change) |
|||
| Line 20: | Line 20: | ||
* We won't bring up Mozilla 2 on mobile devices (but volunteers are welcome to port early and often; Mozilla 2 will fit on such devices much more easily than Mozilla 1 code does). | * We won't bring up Mozilla 2 on mobile devices (but volunteers are welcome to port early and often; Mozilla 2 will fit on such devices much more easily than Mozilla 1 code does). | ||
The goals boil down to competing more effectively with ourselves, with [http://webkit.org Webkit], and even with IE and Opera, for all three of the Web, XUL (or equivalent "widget" or "rich client platform" | The goals boil down to competing more effectively with ourselves, with [http://webkit.org Webkit], and even with IE and Opera, for all three of the Web, XUL (or equivalent "widget" or "rich client platform" comparable), and C++ embeddable HTML rendering engine platforms. We should aspire to beat the competition on major time, space, and ease-of-use axes, not just show or place. | ||
=== Means === | === Means === | ||
| Line 39: | Line 39: | ||
** Extract GC from Tamarin (e.g. remove all fp dependencies) (??) | ** Extract GC from Tamarin (e.g. remove all fp dependencies) (??) | ||
** Ensure GC/Taramin compiles/runs on all platforms | ** Ensure GC/Taramin compiles/runs on all platforms | ||
* Rich Graphics Plan (Q207) | * Rich Graphics Plan (Q207) | ||
** Video Prototypes (Chris D) | ** Video Prototypes (Chris D) | ||
| Line 47: | Line 46: | ||
* Security Plan (Q207) | * Security Plan (Q207) | ||
* Layout Plan (Q207) | * Layout Plan (Q207) | ||
* < | * <del>Finalize choice of VCS and implement</del> | ||
==== Timeline ==== | ==== Timeline ==== | ||
| Line 61: | Line 60: | ||
* Q307 | * Q307 | ||
** Tamarin GC Building on all major platforms | ** Tamarin GC Building on all major platforms | ||
** First | ** First prototype of Tamarin | ||
** Design/Prototypes done for each major area | ** Design/Prototypes done for each major area | ||
* Q407 | * Q407 | ||
** First Alpha of Moz2/Gecko2/ | ** First Alpha of Moz2/Gecko2/Fx4 released | ||
* Q108 | * Q108 | ||
** | ** Fx4 Alphas | ||
** All Major design work done | ** All Major design work done | ||
* Q208 | * Q208 | ||
** First | ** First Fx4/Moz2 Beta | ||
* Q308 | * Q308 | ||
** Betas | ** Betas | ||
* Q408 | * Q408 | ||
** Moz2/ | ** Moz2/Fx4 Ship | ||
==== A Better VCS (Brendan/Preed) ==== | ==== A Better VCS (Brendan/Preed) ==== | ||
See [[VersionControlSummit2006 | the great Version Control System shoot-out]]. We need a better VCS because Mozilla 2 will require more sweeping changes, and more experiments which must be run in parallel, than anything we've done so far. So we need at least | See [[VersionControlSummit2006|the great Version Control System shoot-out]]. We need a better VCS because Mozilla 2 will require more sweeping changes, and more experiments which must be run in parallel, than anything we've done so far. So we need at least | ||
* better, cheaper branching | * better, cheaper branching | ||
| Line 85: | Line 84: | ||
* great performance on Windows (this rules out cygwin-ported Linux VCSes) | * great performance on Windows (this rules out cygwin-ported Linux VCSes) | ||
See | See [http://weblogs.mozillazine.org/preed/2006/11/version_control_system_shootou.html preed's Mortal Kombat] salute and look for news on his blog. | ||
An important aspect to get straight is the branching topology. We will have many unstable branches running concurrently during Moz2 development. Generally for each task you want sub-task branches (possibly per-author or per-feature) plus a task-integration branch that your group tries to keep building and working most of the time. The ability to chain a new branch to a new buildbot, with a minimum of fuss, is very helpful. | An important aspect to get straight is the branching topology. We will have many unstable branches running concurrently during Moz2 development. Generally for each task you want sub-task branches (possibly per-author or per-feature) plus a task-integration branch that your group tries to keep building and working most of the time. The ability to chain a new branch to a new buildbot, with a minimum of fuss, is very helpful. | ||
| Line 101: | Line 100: | ||
* Dynamic optimizations for untyped JS (both Web and XUL JS -- we won't require all XUL JS to be annotated with types). | * Dynamic optimizations for untyped JS (both Web and XUL JS -- we won't require all XUL JS to be annotated with types). | ||
* Profile-directed Ahead Of Time compilation for critical methods (in lieu of XUL FastLoad, to avoid taking a startup performance hit). | * Profile-directed Ahead Of Time compilation for critical methods (in lieu of XUL FastLoad, to avoid taking a startup performance hit). | ||
* Fresh thinking and hacking for VM-based security, learning from [[Security:Bibliography | recent security research]]. | * Fresh thinking and hacking for VM-based security, learning from [[Security:Bibliography|recent security research]]. | ||
We hope to self-host a JS2 compiler on the VM, but if performance can't match or beat the competition (including today's SpiderMonkey), we will have to consider: | We hope to self-host a JS2 compiler on the VM, but if performance can't match or beat the competition (including today's SpiderMonkey), we will have to consider: | ||
| Line 107: | Line 106: | ||
* Native compiler front end. | * Native compiler front end. | ||
While "it would be nice" (sincerely; but also, these are famous last words) to optimize the VM such that the self-hosted compiler beats a C or C++ hand-crafted compiler, we cannot put purity ahead of performance. The trade-off for Tamarin's embedding in the Flash Player is different: offline compilation via the Flex SDK is the rule there, and the self-hosted compiler need only be fast enough for < | While "it would be nice" (sincerely; but also, these are famous last words) to optimize the VM such that the self-hosted compiler beats a C or C++ hand-crafted compiler, we cannot put purity ahead of performance. The trade-off for Tamarin's embedding in the Flash Player is different: offline compilation via the Flex SDK is the rule there, and the self-hosted compiler need only be fast enough for <code>eval</code> requirements (which will be novel to Flash in a future release). | ||
Current DOM security checks use the [[Security:Scattered Security Checks]] model. For Mozilla 2, in order to JIT DOM calls efficiently, we need either [[Security:Security Checks In Glue]] or [[Security:Wrapper-based Checks]]. To support "mashups in the browser" and [http://www. | Current DOM security checks use the [[Security:Scattered Security Checks]] model. For Mozilla 2, in order to JIT DOM calls efficiently, we need either [[Security:Security Checks In Glue]] or [[Security:Wrapper-based Checks]]. To support "mashups in the browser" and [http://www.w3.org/TR/XBL XBL2], we may need to support data-tainting with static flow analysis as well as dynamic taint propagation. | ||
==== Semi-automated refactoring work/Oink ==== | ==== Semi-automated refactoring work/Oink ==== | ||
[[Static Analysis]] via [[FirefoxSummit/2006/ProposedSessions/Oink | Oink]] will play an important role, we think, in partially or fully automating | [[Static Analysis]] via [[FirefoxSummit/2006/ProposedSessions/Oink|Oink]] will play an important role, we think, in partially or fully automating | ||
* deCOMtamination, including getting XPCOM completely out of the middle of Gecko | * deCOMtamination, including getting XPCOM completely out of the middle of Gecko | ||
| Line 124: | Line 123: | ||
* simple metrics of code complexity, to be regularly compared to other open source projects | * simple metrics of code complexity, to be regularly compared to other open source projects | ||
Other good ideas for Oink-based tools should be noted [[ | Other good ideas for Oink-based tools should be noted on [[Static Analysis]]. The "conversion" items above will use the to-be-written (but proven-in-concept) pattern-matching patch-generating tool discussed at [http://weblogs.mozillazine.org/roadmap/archives/2006/11/oinkbased_patch_generation.html another this blog post]. | ||
| Line 139: | Line 138: | ||
** convert all paint methods to take gfxContext instead of nsIRenderingContext | ** convert all paint methods to take gfxContext instead of nsIRenderingContext | ||
** optimize API usage, e.g. take advantage of new clipping/transform capabilities | ** optimize API usage, e.g. take advantage of new clipping/transform capabilities | ||
* Add optional acceleration using OpenGL (or Direct3D) | * Add optional acceleration using OpenGL (or Direct3D) | ||
** Involves work to make widget layer 3D-aware | ** Involves work to make widget layer 3D-aware | ||
* Add video capabilities to platform, combined with hw accel and complex transform capability | * Add video capabilities to platform, combined with hw accel and complex transform capability | ||
* Make 3D a first-class citizen of platform | * Make 3D a first-class citizen of platform | ||
** any | ** any 2D element should render correctly under an arbitrary 2D transform | ||
* Tighter integration between image decoding and rendering | * Tighter integration between image decoding and rendering | ||
** decode-on-render | ** decode-on-render | ||