The Firefly science advisory panel has discussed the desired behavior for Firefly across multiple applications in respect of the toolkit's ability to fall back to creating a 2D histogram ("heat map") in cases where a user requests too many points for a scatterplot.

We recommend the following for implementation:

• If the user explicitly requests a 2D histogram (“heat map”), via API or UI action, they get that no matter what. It never changes to a scatterplot.
• If the user requests a scatterplot, but there are more than N_hist (an application-configurable parameter) rows in the associated table, the plot is generated and displayed as a 2D histogram, but it is internally marked as “really” being a scatterplot.
• Then if, as a result of filtering or some other action that changes the size of the table, the number of points falls back to or below N_hist, the plot is regenerated and displayed as a scatterplot.
• This applies regardless of whether the filter is applied to some other variable(s) in the table or to the plotted variables themselves. Thus, for example, if the user draws a selection rectangle on the 2D histogram - effectively “zooming in” on a region - which selects N_hist or fewer points, and clicks on the “filter” button on the plot, the selected region will be re-drawn as a scatterplot.
• There may be a second application-configurable size-limit parameter, less than or equal to N_hist, which I’ll call N_GL, which controls a transition between “traditional” Plotly scatterplots and Plotly WebGL scatterplots, with the latter used when the number of points exceeds N_GL. The parameterization must allow an application to set N_GL = N_hist or use some equivalent means of requiring that the WebGL scatterplot never be used. (Eventually, however, we hope that the WebGL scatterplots become a complete replacement for the traditional ones.)

This issue has already been through "FireflyCCB-D"-style review and we are requesting implementation.

The schedule should be discussed at today's CCB meeting. Gregory Dubois-Felsmann, at least, views this as a high-priority item, with the current behavior leaving an unfavorable impression of Firefly's ability to handle large datasets.