Since the code of your renderer plugins is executed in a browser, it is important to write optimized code and pay special attention to performance issues. If your plugin works well on powerful machines, it might work unstable on other, less powerful, users' machines.
To ensure that your renderer plugin has been properly optimized to perform well in any of the above cases, check that:
- The renderer plugin prepares the data in a reasonable time.
- A sufficient number of tiles can be opened concurrently.
Also, follow the practices below while developing your rendering plugin. These practices allow you to avoid some of the most common performance issues related to data visualization.
For more information on general recommendations for developers on how to use Data Inspector Library components, see Best Practices for Developers.
Try not to represent all your data graphically, especially for large datasets. Otherwise, your renderer plugin can generate the GeoJSON that is too big to be rendered. Be aware that all sorts of users may use different browsers on different machines. So, do all your tests on the latest versions of Safari, Chrome, and Firefox and try them out on lower-end machines. It is recommended that you control the number of GeoJSON features to be rendered and not exceed the limit of memory allocated by browsers.
Having a big number of rendered objects on the map also makes it difficult to analyze the data visually since a lot of objects might be overlapped in the same area. That is why it is a good idea to create a variable in the code where users can specify a feature identifier, such as Vehicle ID, to render objects related only to this feature. Such filtering approach helps improve both analysis capability and performance.
Do not try to add too many data details into GeoJSON
description informational properties. The concept of tooltip implies that only a short string is displayed in it, and for displaying detailed information
description property is used. Still it is better not to add too much data into
description as well.
Use the output of the Decoded Panel for a deeper analysis of GeoJSON features, geometries, and properties. Given that the entire GeoJSON generated by a renderer plugin with all the data in the feature properties passes through the Web Worker, much of your browser's allocated resources are consumed. That is why, too many additional information in the feature might cause your browser to crash.
Also, it is recommended to avoid usage of HTML in descriptions, it is better to use a key-value object, which will be represented as a table by
If GeoJSON feature has a lot of underlying information, please use the
protobufRef property to map GeoJSON features generated by the plugin to the corresponding source data objects.
Always optimize your data processing operations since it could be megabytes (or even gigabytes) of decoded data that has to be processed locally by a renderer plugin. Do not overuse loops, recursions, data conversion, and data formatting (stringify, replace operations are too expensive).
Profile your renderer plugin before publishing to find and optimize any weak spots.
Test your plugins on a machine with mediocre performance to be sure that it does not cause browser crash. Note that currently the max number of tiles that can be rendered at the same time is 64.
If you intend to implement the async
getGeoJSONAsync function in your renderer plugins, you must make sure that promises always reject in case of runtime errors. Otherwise, if a promise is neither resolved nor rejected, plugin execution stalls, and users won't get any notifications about runtime errors in the plugin.
To make it easier, the recommended way is to use the ES6
async/await syntax. This ensures that any exceptions thrown inside any of the
async functions called from the main
getGeoJSONAsync function will always reject its promise. If you prefer using the
Promise syntax over the
async/await syntax sugar, you must be sure that these promises always reject in case of errors. Use
try/catch to track any possible errors.