Fix feature-state dependent styles for *-pattern properties

[mollymerp]

per #6289 (comment)

In the recent addition of data-driven styling support for *-pattern properties, feature-state dependent expressions do not work. The removal of the possibleOutputs state (#6289 (comment)) makes it possible that the icons needed forfeature-state related paint array updates may not be available in the tile's ImageAtlas at update time.

We haven't run into this before because the other data-driven properties that require glyph/icon assets are layout properties which don't support feature-state expressions yet.

I see a couple options on how to fix this:

• request new images in the CrossFadedCompositeBinder#updatePaintArrays method that runs on the main thread when feature states are updated/changed and update the tile's ImageAtlas
  • 👎 binder would need access to ImageManager, binder would have to send the new ImageAtlas to the tile somehow
• pass available feature-states to the buckets at parse time so the expressions can be evaluated with feature state and all needed images can be requested
  • 👎 additional payload on worker thread transfer, doesn't cover the case where no features have the state value that is used in the expression when it is set as a paint property
• reintroduce possibleOutputs state and require that feature-state dependent expressions for cross-faded-data-driven properties be contained as literals
  • 👎 lots of special-case logic and behavior, might be confusing/unexpected to users
• not support feature-state expressions for cross-faded-data-driven properties
  • 👎 this is the current behavior, but it fails silently

leaning towards the first option here, but curious if anyone has a different preference or another idea.
cc @asheemmamoowala @jfirebaugh

[jfirebaugh]

I lean toward the first option, although it sounds like we have a few other issues also pushing us towards the second one.

Overall, it feels to me like we might have to think about rearchitecting how we partition work to the worker.

• Divide it up much more granularly -- per bucket.
• Use SharedArrayBuffer to share feature data?
• Have the option of doing certain buckets synchronously on the main thread where necessary. Like Add a synchronous version of GeoJSONSource#setData #2275 but maybe for other cases too, like when a property uses feature-state or when setLayoutProperty is used.

[charandas]

Any update on this @mollymerp?

[charandas]

I would love some attention on this from the team, it's holding me on a fork since the days of #6289.

[asheemmamoowala]

@charandas currently there are no plans to implement this because it requires a lot of effort to implement, and our team is focused on higher priority issues at the moment.

[songololo]

Would it please be possible to explicitly state in the docs which style specs are supported by feature-state operations?

[asheemmamoowala]

@songololo Thank you for the suggestion. It turns out that we already have the relevant infromation to update the docs. You can follow the docs update in https://github.com/mapbox/mapbox-gl-js-docs/pull/171

[asheemmamoowala]

Native PR is moving at: mapbox/mapbox-gl-native#15872