-
Notifications
You must be signed in to change notification settings - Fork 75
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
Update styles from arrays #683
Comments
+1 |
LRTM |
I think thats fine and as discussed we can document this. As you stated, while animating, the end-users has responsibility to make sure their data is correct. As far as we can generate reasonable error messages (**whenever possible because in some cases the error may be from GL in which case we cannot do much about it). |
Do we do that? or should be ask users to give us an array of values? |
I think that should be fine. Per vertex thing would be for users who knows graphics and programming at a deeper level. For them then can grab the GL bufffers I would think. |
Yes, 15 FPS min +1 |
We run style color values through a function that returns an object with |
I see, I think for now for consistence {r:, g:, b:} is fine. i am wondering if we could call this method |
Other than that I think I am good with overall idea. We could probably file a bug for supporting animations of position as well if it is not there already. |
|
Animating positions is intrinsically slower than other properties due to coordinate systems. The data is in the As a complication, lines and polygons have coordinates per vertex (necessarily), so updating the style via an array per data item doesn't work there, either. A function (in the future) could be written to handle this, but the interface is a lot less obvious -- should this now be an array of arrays (probably)? or a single concatenated array. Polygons with holes are complicated. Again, we can expose speed-ups on a per feature basis -- points could allow updating geometry via an array, and the coordinate system conversion would cost some time, but it would still be faster than the current method. Other features would simply not support updating position by array for now. |
roger that |
right. And actually for lines I would think that we will have to be bit more creative. I see a level in animation based on positions:
|
I agree +1 |
Make sense, points would be most obvious and doable for now. |
I've got a fist pass of this working on my local machine, with just the pointFeature optimized for radius, fill, fillOpacity, stroke, strokeOpacity, and strokeWidth. Initially, while animating 4 styles (radius, fillOpacity, strokeOpacity, and strokeWidth) with 10% of the points having any opacity in any given frame, I get 60 fps for 500,000 points, 30 fps for 1,000,000 and 15 fps for 2,000,000. |
Resolved by PR #687. |
Previously, we've animated line and point features by getting access to the WebGL
Float32Array
s used for specific styles, such as opacity or color, modified those arrays, and then rerendered. This is very fast, but requires knowledge of internal data structures. For unclustered points, for instance, each point has a a record that has some number of vertices per point (which could be 1, 3, or 4 depending on how we constructed the point feature). The user has to know to use this value.As an alternative, if we added a function to set styles from arrays, the generic mode would just update that style by converting the array to a function:
The
styleArray
contents in this example would be not be functions. This means for lines and polygons, there would be one value for each line or polygon regardless of how many line segments or vertices they had.Perhaps this could also take a dictionary of style keys and their associated arrays as a convenience to avoid having to call the function multiple times for multiple concurrent style changes.
For features where we chose to optimize things, the subclass could provide an extra method to accelerate updates. For instance, in the gl_pointFeature, this function could be:
There are a few dangers to this optimization: (a) the values extracted from
styleArray
are not checked for validity, so passing bad values will do odd things, (b) for efficiency some styles will be necessarily more restrictive than they are in general. For instance, colors would need to be in {r: , g: , b: } rather than our permissive css possibly with opacity processing we currently do, (c) it may not work with certain features, such as point clustering, (d) this doesn't give access to per-vertex values of lines and polygons. All of this could be worked around, but for animations, speed is paramount, so any checks and validation need to be very quick -- for instance, we could skip the fast path if points are clustered.Thoughts?
The text was updated successfully, but these errors were encountered: