diff --git a/dev-docs/RFCs/README.md b/dev-docs/RFCs/README.md index dcdf2a3c4de..dc006bd5e7c 100644 --- a/dev-docs/RFCs/README.md +++ b/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. diff --git a/dev-docs/RFCs/v7.x-binary/binary-data-rfc.md b/dev-docs/RFCs/v8.x/binary-data-rfc.md similarity index 100% rename from dev-docs/RFCs/v7.x-binary/binary-data-rfc.md rename to dev-docs/RFCs/v8.x/binary-data-rfc.md diff --git a/dev-docs/RFCs/v7.x-binary/chunked-data-support-rfc.md b/dev-docs/RFCs/v8.x/chunked-data-support-rfc.md similarity index 100% rename from dev-docs/RFCs/v7.x-binary/chunked-data-support-rfc.md rename to dev-docs/RFCs/v8.x/chunked-data-support-rfc.md diff --git a/dev-docs/RFCs/v7.x-binary/glsl-accessor-rfc.md b/dev-docs/RFCs/v8.x/glsl-accessor-rfc.md similarity index 100% rename from dev-docs/RFCs/v7.x-binary/glsl-accessor-rfc.md rename to dev-docs/RFCs/v8.x/glsl-accessor-rfc.md diff --git a/dev-docs/RFCs/v7.x-binary/gpu-data-frame-rfc.md b/dev-docs/RFCs/v8.x/gpu-data-frame-rfc.md similarity index 100% rename from dev-docs/RFCs/v7.x-binary/gpu-data-frame-rfc.md rename to dev-docs/RFCs/v8.x/gpu-data-frame-rfc.md diff --git a/dev-docs/RFCs/v7.x-binary/texture-attribute-rfc.md b/dev-docs/RFCs/v8.x/texture-attribute-rfc.md similarity index 100% rename from dev-docs/RFCs/v7.x-binary/texture-attribute-rfc.md rename to dev-docs/RFCs/v8.x/texture-attribute-rfc.md diff --git a/dev-docs/roadmaps/dist-size-roadmap.md b/dev-docs/roadmaps/dist-size-roadmap.md index 7e45f3c2048..4b528a6416d 100644 --- a/dev-docs/roadmaps/dist-size-roadmap.md +++ b/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 diff --git a/dev-docs/roadmaps/infovis-roadmap.md b/dev-docs/roadmaps/infovis-roadmap.md index 4d867efd724..d6b9637d301 100644 --- a/dev-docs/roadmaps/infovis-roadmap.md +++ b/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 - - diff --git a/dev-docs/roadmaps/layers-roadmap.md b/dev-docs/roadmaps/layers-roadmap.md index 8b509fe4f51..c18129cd195 100644 --- a/dev-docs/roadmaps/layers-roadmap.md +++ b/dev-docs/roadmaps/layers-roadmap.md @@ -2,78 +2,28 @@ * **Authors**: Ib Green, Shaojing Li... - ## Motivation -Most people use deck.gl through the layers that we provide with it and additions to the layer catalog are a good way to increase the use cases supported by deck.gl. - -In the next version of deck.gl, we want to add more layers to the layer catalog. - - -## Multiple Layer Catalogs - -With more layers in our layer catalog, we should consider reorganizing the layers for easier navigation. We could put our core layers into different folders, such as non-geo and geo. We can also consider moving the entire layer catalog out of core deck.gl repo and ask our users to import new packages. - -* Core Catalog - `@deck.gl/layers` -* 3D Layers - `@deck.gl/3d-layers` -* Advanced Geospatial Layer Catalog - `@deck.gl/geospatial-layers` -* Trips Layer Catalog - `@deck.gl/trip-layers` -* Infovis Layer Catalog - `@deck.gl/infovis-layers` - +Most people use deck.gl through the layers that we provide with it and additions to the layer catalog are a good way to increase the use cases supported by deck.gl. We gradually want to add more layers to the layer catalog. ## Generalized Aggregation Layers We have an increasing number of "aggregating" layers. Can the aggregator code be generalized into a reusable "AggregationManager" that can be attached to existing layers without subclassing or with minimal subclassing. - -## Core Catalog - -The core deck.gl catalog (@deck.gl/layers) contains mainly 2.5D layers appropriate for geospatial visualizations and as general building blocks. - - -### BitmapLayer (EXPERIMENTAL) - - -Renders a set of bitmaps on a certain altitude. - - -### HeatmapLayer (2D color heatmap) - -Similar to our Hexagon layer but instead of rendering hexagon or square bars, it does the aggregation and renders some interpolated - - -### TextLayer (IMPLEMENTED) - -Renders text labels in screen space. There are multiple solutions to text rendering. TextLayer can be implemented as a composite layer containing an IconLayer with pre-rasterized textures, or as a dynamically composed set of labels. - - ### Vector Field Layer ### Particle Layer -... - - -## Core Catalog Improvements - - -### ScatterplotLayer - -* Outlines... - - ### ArcLayer * Height of the arcs * Style of the lines - ### IconLayer * Rotation angles * World oriented labels - ### PathLayer * Different widths at the beginning and end of path segment @@ -83,37 +33,12 @@ Renders text labels in screen space. There are multiple solutions to text render ### GridLayer * Add coverage, lowerPercentile, upperPercentile, getColorValue to GridLayer to make it aligned with HexagonLayer -### All Layers - -* Default selected highlight color support - - - - ## 3D Layer Catalog -Propose: `@deck.gl/3d-layers` - -### MOVE? PointCloudLayer - -We might potentially want to move the `PointCloudLayer` to this catalog. - - ## NEW 3D Polygon Layer Polygon layer where baselines can also be adjusted. - -### NEW - MeshLayer (EXPERIMENTAL) - -A general instanced layer that takes whatever geometry that the app provides to the deck.gl. We should support full 3D transformation. - - -### NEW - ScenegraphLayer (A general non-instanced layer) - -A general layer that takes a set of luma.gl geometries and renders it. - - ### NEW - ThreeJSScene layer A layer that takes a THREE.js scene and renderers it. @@ -122,56 +47,52 @@ We will need to see how we bridge the react world with the THREE.js world so tha 3DSceneLayer A layer that also renders a 3D scene with our custom scene graph solutions. Comparing the the ThreeJSSceneLayer, this will feature our custom scene graph algorithms. - - -## Advanced Geospatial Layer Catalog - -Propose a `@deck.gl/geospatial-layers` module with a catalog of specialized geospatial layers - -### GeoJsonLayer - -The GeoJsonLayer could potentially be moved to this catalog. Although it admittedly is quite useful even in some non-geospatial contexts. - -### H3Layer - -### H3OutlineLayer - -### S2Layer - ### S2OutlineLayer ### TopoJSONLayer People would like us to support more standard data format so they could simply plug their data in and expect to have something rendered on their screen. TopoJSON has been requested by our users (https://github.com/uber/deck.gl/issues/591) - - ## Trips Layer Catalog One of our most important data items are trips, we could collect the various layers we have built and customized for trips into a separate layer catalog. +## Implemented + +### Multiple Layer Catalogs + +With more layers in our layer catalog, we should consider reorganizing the layers for easier navigation. We could put our core layers into different folders, such as non-geo and geo. We can also consider moving the entire layer catalog out of core deck.gl repo and ask our users to import new packages. + +* Core Catalog - `@deck.gl/layers` +* 3D Layers - `@deck.gl/3d-layers` +* Advanced Geospatial Layer Catalog - `@deck.gl/geospatial-layers` +* Trips Layer Catalog - `@deck.gl/trip-layers` +* Infovis Layer Catalog - `@deck.gl/infovis-layers` +### ScenegraphLayer -## Infovis Layer Catalog +A general layer that takes a set of luma.gl scenegraphs and renders them as instances -Propose a `@deck.gl/infovis-layers` catalog. NOTE: infovis functionality has its own roadmap document. +### H3Layer -### Node-link layer +### H3OutlineLayer -like geojson-layer, a composition of node (scatterplot, icon) and link (line, path, curve) layers +### S2Layer -### Matrix layer +### ScatterplotLayer -basically a variation of the screen grid layer - geoEncode +* Outlines... +### BitmapLayer -## Math Layer Catalog? +### MeshLayer -Currently have not seen much demand but it would be nice to have some "math" visualization layers. +A general instanced layer that takes whatever geometry that the app provides to the deck.gl. We should support full 3D transformation. -### Improved Plot Layer +### HeatmapLayer -### Complex Surface Layer +Similar to our Hexagon layer but instead of rendering hexagon or square bars, it does the aggregation and renders some interpolated -... +### TextLayer +Renders text labels in screen space. There are multiple solutions to text rendering. TextLayer can be implemented as a composite layer containing an IconLayer with pre-rasterized textures, or as a dynamically composed set of labels. diff --git a/dev-docs/roadmaps/lighting-roadmap.md b/dev-docs/roadmaps/lighting-roadmap.md deleted file mode 100644 index 8ccccc1956e..00000000000 --- a/dev-docs/roadmaps/lighting-roadmap.md +++ /dev/null @@ -1,27 +0,0 @@ -# Lighting Roadmap - - - - -## Motivation -A flexible and featureful lighting module is highly expected by users, could bring rendering quality to a new level. - -## Major Features - - -### Different Light Sources Per Deck - -* Ambient light -* Point light -* Directional light - - -### Material Parameters Per Layer - -* Ambient -* Diffuse -* Specular -* Shininess - - -### Shadow Casting