fill blurring

[ansis]

Partially ports blurring from -native. Setting the following properties on a fill bucket blurs the fill:

{
    "prerender": true,
    "prerender-size": 1024,
    "prerender-blur": 1
}

prerender and prerender-size can't be functions yet, unlike native. I think we need some deeper thought reorganization here.

@mourner quick review?

[mourner]

console.log

[mourner]

Looks great. But prerender props should be specified in styles, not bucket, right? And what reorganization would we need to support functions? Are you concerned about performance here?

[ansis]

But prerender props should be specified in styles, not bucket, right?

Nope, these need to be on the bucket. It pre-renders a blurred texture for the tile once, and just linearly interpolates after that. This follows the -native implementation.

And what reorganization would we need to support functions?

Functions for buckets aren't supported yet

Are you concerned about performance here?

Drawing from the texture on each frame is fast. Its just the first frame that requires some extra processing. Its hard to measure carefully, but it feels fine. I'm not seeing any low-hanging optimizations, and performance concerns will be similar to those on -native.

[mourner]

@ansis currently the only reason bucket and style properties are separated is that bucket properties are needed when extracting data in a worker. This code doesn't have any worker calculations. Also, native style has them specified in styles: https://github.com/mapbox/mapbox-gl-native/blob/master/bin/style.js#L2070-L2072

[ansis]

@mourner you're right about -native having them in the style. I missed that

This feels odd to me. All other current style properties can be changed at render time without reprocessing the data, just by tweaking uniforms. Changing the prerender properties means prerendering the tile again. But as you mentioned, the buffers don't need to be reprocessed in the workers.

Also, in -native these properties are functions of the tile zoom, not the current zoom, unlike all style properties. What I'm wondering is how special cases like this should change how we deal with the style

[yhahn]

@ansis can you recreate this pull against the dev-pages branch?