GPU Aggregation (4/8): ScreenGridLayer

[Pessimistress]

For #7457

Change List

• Move ScreenGridLayer to use new AggregationLayer and aggregator classes
• Update tests

[felixpalmer]

Is this always going to be true? Could there not be extensions which CellLayer will need?

[Pessimistress]

For ScreenGridLayer there's no existing extension that should be applied to the cells directly, and unlikely for any custom extensions.

This will be tricky for GridLayer/HexagonLayer. FillStyleExtension and TerrainExtension should affect the screen pass only, and *FilterExtension should affect the aggregation pass only.

We could add some flag to the extensions to categorize them?

[felixpalmer]

Would it be sufficient for the extension to signal which stage of the GPU pipeline it affects? E.g. 'vertex'/'fragment'. The aggregation pass should only use the 'vertex' extensions and the screen pass the 'fragment'.

Even so, how does this work for DataFilterExtension? There we would like the vertex shader injections to hide the filtered data points before aggregation, but in the screen pass the dataFilter_value needs to both shrink the geometry in the vertex stage & fade in the fragment stage

An alternative would be to have the extensions understand the concept of what context they are being invoked in, by looking at what type of Pass they are being rendered in. The DataFilterExtension could then do one thing in the AggregationPass and another in the ScreenPass

[coveralls]

coverage: 89.222% (-0.2%) from 89.454%
when pulling 122449b on x/aggregation-4
into b8f9181 on master.

[coveralls]

coverage: 89.222% (-0.2%) from 89.454%
when pulling 9127f6d on x/aggregation-4
into b8f9181 on master.

[coveralls]

coverage: 89.281% (-0.2%) from 89.454%
when pulling 7dcb805 on x/aggregation-4
into b8f9181 on master.