Merge 7a6c075 into 66a7264

dev-docs/RFCs/README.md

@@ -19,7 +19,7 @@ Also see luma.gl roadmaps, such as the GPGPU roadmap
 | [**Animation Roadmap**](../roadmaps/animation-roadmap.md)          | Draft        | Animation API roadmap |
 | [**Performance Roadmap**](../roadmaps/performance-roadmap.md)      | Draft        | Performance Improvements |
 | [**Infovis Roadmap**](../roadmaps/infovis-roadmap.md)              | Draft        | Infovis (non-geospatial) features roadmap |
-| [**Reduce Distribution Size**](../roadmaps/dist-size-roadmap.md)   | Ongoing      | Reduce size of distribution and the bundle size of applications using deck.gl |
+| [**Reduce Distribution Size**](../roadmaps/dist-size-roadmap.md)   | Implemented  | Reduce size of distribution and the bundle size of applications using deck.gl |
 | [**Pure JS and Scripting Roadmap**](../roadmaps/purejs-roadmap.md) | Implemented  | Support for Scripting and Pure-JS APIs |
 
 
@@ -49,7 +49,7 @@ Possible other animation related RFCs:
 | [**Unified ViewState**](vNext/view-state-rfc.md) | @ibgreen | **Deferred** | Controversial proposal for an even more Unified View/Controller Architecture. Review again after all Controller/Multiview RFCs have been approved/implemented |
 
 
-## v7.x Binary Data RFCs
+## v8.x Binary Data RFCs
 
 Group of related RFCs loosely targeted for 7.x releases.
 

dev-docs/roadmaps/dist-size-roadmap.md

@@ -10,7 +10,6 @@
 
 It is the premise of this document that there is no single silver bullet to help us solve the distribution size issue. While we'd love to be proven wrong, it is expected that we will have to apply a combination of continued efforts in multiple areas and be thoughtful about how we organize code going forward.
 
-
 ## Critera
 
 To make meaningful progress, we need to define some measurement criteria:
@@ -19,18 +18,11 @@ To make meaningful progress, we need to define some measurement criteria:
 * Size of bundle before application minification (debug)
 * Easy of debugging
 
-While one might be tempted to focus on prod sizes, many users look at the debug sizes (which affects build/load/debug cycle speeds) so optimizing both are important.
-
-
-## Progress
-
-A lot has already been done, see the sections towards the bottom of this doc for details.
+While one might be tempted to focus on prod sizes, many users look at the debug sizes (which affects build/load/debug cycle speeds) so optimizing both are important. Script sizes also matter.
 
+> A lot has already been done, see the sections towards the bottom of this doc for details.
 
-## Proposed Techniques
-
-Ordered loosely after expected size savings
-
+## Proposals
 
 ### Proper Minification Techniques
 
@@ -60,43 +52,12 @@ There are three known techniques to achieve this in JavaScript:
 * Subdirectory Imports - NOT USED, DUE TO TECHNICAL COMPLICATIONS
 
 
-### Tree-Shaking
-
-STATUS: PARTIALLY SUPPORTED, NEEDS MORE WORK
-EFFORT: MODEST (doing some improvements on current state)
-
-Requires a separate distribution that does not transpile ES6 module statement.
-
-We have added tree-shaking examples to our repos. We can build a minimal app that uses almost no symbols from the lib and inspect what actually gets bundled (a lot is still bundled, but some things do get "shaken out").
-
-* Only supported by certain bundlers, such as Webpack 4 (most of our users are likely on webpack, so we'll focus on Webpack 4)
-* Webpack2 only gets three-shaking during minification through UglifyJs, so has no effect on debug builds.
-* Tree shaking of functions works fairly well
-* Tree shaking of classes has problems, due to transpiled class declarations looking like "side effects", requires build tricks to (partially) work around
-
-WORK ITEMS:
-* Continue to refine our libraries to work with tree-shaking, combat tree-shaking-defeating "side effects" so that less unused symbols are included.
-* Get rollup working for deck (only works for luma today) so we have two points of reference
-
-WEBPACK 2
-* UglifyJS support for ES6 is not strong, tree shaking must be done on transpiled code
-
-
 ### Subdirectory Imports
 
 STATUS: HAS SEVERE ISSUES, NOT PURSUED
 
 This technique (offering subdirectory imports `import ScatterplotLayer from 'deck.gl/scatterplot-layer'`) has serious complications when combined with tree shaking. Unless we can solve these this technique can not be used in deck.gl.
 
-
-
-## Additional Ideas
-
-### Inline GL constants
-
-Write a babel plugin to inline GL constantss
-
-
 ### Remove asserts in production
 
 Write a babel plugin to strip asserts
@@ -111,10 +72,32 @@ WORK ITEM:
 * If good results, include example/recipe in our webpage
 * Use in our own apps
 
+## Implemented
+
+### Inline GL constants
+
+Write a babel plugin to inline GL constantss
+
+### Tree-Shaking
+
+STATUS: PARTIALLY SUPPORTED, NEEDS MORE WORK
+EFFORT: MODEST (doing some improvements on current state)
+
+Requires a separate distribution that does not transpile ES6 module statement.
+
+We have added tree-shaking examples to our repos. We can build a minimal app that uses almost no symbols from the lib and inspect what actually gets bundled (a lot is still bundled, but some things do get "shaken out").
 
+* Only supported by certain bundlers, such as Webpack 4 (most of our users are likely on webpack, so we'll focus on Webpack 4)
+* Webpack2 only gets three-shaking during minification through UglifyJs, so has no effect on debug builds.
+* Tree shaking of functions works fairly well
+* Tree shaking of classes has problems, due to transpiled class declarations looking like "side effects", requires build tricks to (partially) work around
 
-## Implemented Improvements
+WORK ITEMS:
+* Continue to refine our libraries to work with tree-shaking, combat tree-shaking-defeating "side effects" so that less unused symbols are included.
+* Get rollup working for deck (only works for luma today) so we have two points of reference
 
+WEBPACK 2
+* UglifyJS support for ES6 is not strong, tree shaking must be done on transpiled code
 
 ### Publishing Separate Packages
 
@@ -130,14 +113,12 @@ This is mostly helpful when we have parts of the library that are clearly option
 NEXT STEPS:
 * We'd need to define a meaningful separation into sub-packages - if most apps end up importing all the modules we haven't really gained anything.
 
-
 ### Use Automatic Attribute Updaters
 
 Status: IMPLEMENTED - at least for the easy use cases
 
 Most layer attribute updaters are doing the same thing which could easily be automated, especially if we had prop types for accessors. This could remove 10-20% of the code from each layer, at the cost of layer source code being a little less easily understood.
 
-
 ### Dependency Reduction
 
 Eliminate dependencies, as we cannot control how their sizes evolve.
@@ -147,7 +128,6 @@ Status: IMPLEMENTED
 
 luma.gl and deck.gl now have a minimal number of dependencies.
 
-
 ### Replace gl-matrix with custom math library
 
 Status: IMPLEMENTED
@@ -158,8 +138,6 @@ gl-matrix takes about 200KB it includes every function many that are never used.
 
 Creating our own math library that handpicks the most common functions from the stack-gl versions of these libraries brings the size down to about 60KB and can make this code more amenable to tree-shaking.
 
-
-
 ### Remove v4.0 Deprecated Code
 
 Status: IMPLEMENTED
@@ -171,7 +149,6 @@ While the amount of backwards compatible code is generally modest deck.gl contai
 WORK ITEMS:
 * ChoroplethLayers should be removed in next big release.
 
-
 ### Remove Duplicated Code
 
 STATUS: IMPLEMENTED

dev-docs/roadmaps/infovis-roadmap.md

@@ -1,5 +1,27 @@
 # Infovis Roadmap
 
+## Infovis Layers
+
+Propose a `@deck.gl/infovis-layers` catalog. NOTE: infovis functionality has its own roadmap document.
+
+### Node-link layer
+
+Like geojson-layer, a composition of node (scatterplot, icon) and link (line, path, curve) layers
+
+### Matrix layer
+
+Basically a variation of the screen grid layer - geoEncode
+
+## Math Layer Catalog?
+
+Currently have not seen much demand but it would be nice to have some "math" visualization layers.
+
+### Improved Plot Layer
+
+### Complex Surface Layer
+
+...
+
 ## Composable Base Layers
 
 ### Axis Layer
@@ -11,10 +33,8 @@ Scales, ticks etc.
 
 Match axis layer with scales ticks etc.
 
-
+## Implemented
 
 ### Ortographic Controller
 
 Flat zoom and pan, fit bounds
-
-