-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support abritrary expression functions #28
Comments
(I talked with @ansis about this a few weeks ago. Let's see if I can accurately capture the conclusions here.) Arbitrary expressions should be possible, and not pose too much of an issue implementation-wise, if they satisfy the following constraints:
These constraints allow us to continue using the same basic implementation strategy as we currently do:
|
Couple thoughts:
@jfirebaugh I am not sure exactly what these requirements entail. Do they mean that expressions would have to be reducible to the form
{
type: vector,
url: '...',
'computed-properties': [
{ name: 'pop-density', value: 'pop10 / area' }, // assuming pop10 and area are existing properties
{ name: 'pop-sqrt', value: 'Math.sqrt(pop10)' },
{ name: 'pop-density-scaled', value: 'pop-density / 100' } // computed prop using previous computed prop
]
} This would mean that style functions could remain as they are. In some cases this would be less ergonomic than having the expression syntax be part of the DDS function, since it would mean authoring the math in one place (source) and the stops in another (style layer). On the other hand, it might also prove to be a meaningful and useful separation -- especially in cases where multiple style layers need to use the same derived property. |
@anandthakker The main reasons are the two I listed:
We want to avoid unique programs for every layer because compilation and switching programs are the two most expensive operations in GL. Other reasons we don't want to evaluate the property portion of the function in the shader:
Computed properties sound like a good idea. But I don't think we'd want to use a string-embedded syntax for them, but rather whatever "arbitrary expression function" syntax we develop here (or in mapbox/mapbox-gl-style-spec#104). So I see them more of an extension of this issue than a replacement. |
I wonder if there would be an appreciable performance penalty if we
|
The proliferation of function types and desire for more advanced function features keeps bringing me back to the idea of supporting arbitrary expression function types
This is doable so long as we create a syntax that is:
The text was updated successfully, but these errors were encountered: