GeezerVison is showing github.com — Flat architecture for all graphic features · Issue #629 · fastplotlib/fastplotlib
Flat architecture for all graphic features #629DescriptionAn idea for simplifying and solidifying the graphic features API. All graphic features should be flat and have no user-changeable or user accessible attributes, except for .value for features that subclass BufferManager.
Reasoning: currently VertexCmap allows being set like this:
line.cmap = "viridis"`
line.cmap.transform = array_1d
line.cmap.alpha = 0.5 I think this is confusing since it is inconsistent compared to all other graphic features, and it can also make events confusing. For example, what if you want an event for the transform or alpha but no the cmap?
Specific to cmaps for PositionsGraphics we can have an independent cmap_transform feature that only manages the cmap transform and doesn't touch the cmap or alpha. If an alpha is set on the graphic then it will read the alpha value set on the graphic to set that dimension in the final RGBA array to set the colors buffer. Similarly, if a user decides to set VertexColors it will read the alpha feature of that graphic. Perhaps we can allow alpha to be set to None or a float between [0.0, 1.0], can decide this detail later.
Anyways, basic idea is that from our experience I think we can make a formal structure that all GraphicFeatures should follow. Pretty much all of them already follow this except for VertexCmap:
GraphicFeatures should not have any user-end attributes or methods. Except for BufferManagers which have .value.- They must only have one type of event which corresponds to their single settable attribute value (ex. cmap, cmap_transform, alpha, hickness, etc.) and nothing else.
- A
GraphicFeature is allowed to access the other features of a graphic when necessary, for example VertexCmap already does this since it's basically a wrapper for VertexColors. But we can go further with this by for example adding VertexAlpha to set the color alpha of a graphic. I think this makes it really easy to set things on the user-end in an independent way, and to also get precise events.
Implemeting this is trivial, I just have to split up VertexCmap. And we can have this is dev docs somewhere that this is the structure of graphic features. Activityclewis7 commented on Oct 1, 2024 So you are, for example, if someone wanted to change the color map of an image they would do:
image_graphic.cmap.value = "plasma" kushalkolar commented on Oct 1, 2024 image cmap features don't manage a buffer so there's no value attribute, users only acccess .value of a buffer manager attribute if they need array values, they're not settable clewis7 commented on Oct 7, 2024 I think what you have proposed sounds reasonable. Allows us to be more flexible with cmap events and also have more consistency in the graphic features as a whole kushalkolar commented on Oct 18, 2024 I'm now thinking, we should also restrict setting the cmap to an entire line, setting different segments of a line with a different cmap and different transform means that they actually represent different things and should therefore be different lines, or the user should use a line collection.
Keeping track of transforms for different segments of a line just becomes a nonsensical mess for which I cannot think of a sensible scientific usecase. kushalkolar commented on Oct 19, 2024 Another thing I'm doing, making cmap, cmap_transform, and alpha symmetric in LineCollection. It's simpler and it just makes sense. If a user want to apply a cmap to individual lines or have more refined control, they can iterate through the collection to do that. It's also more explicit and clearer. And it's not that hard really to do for line in collection: line.cmap = "jet" kushalkolar commented on Oct 19, 2024 Maybe also we should handle the events at the level of the collection and not just have it propogate from the individual graphics, because that can lead to hundreds of function calls 😆 clewis7 commented on Oct 25, 2024 Per our discussion today:
- update colormaps so that the
cmap property operates at the collection level (i.e. line_collection.cmap = "virdis" will set that cmap across the collection)
- this means if a user wants to change the cmap of an individual line within the collection they should use a for loop or index that particular line
- on the same vein, changing the colors of a line collection will be at the line level not at the vertex level (i.e.
line_collection.colors = "red" will change every line in the collection to red)
- optionally a user could pass a list of strings representing colors (must have same shape as number of lines) to set the individual colors of each line in the collection
- a user would need to do a similar indexing or for loop to change individual color vertices of a given line within a collection
- however, the data component of the line collection will still function as an indexable array that can change individual line data without having to index to that particular line
- this is simply due to the ability of line collection data to be represented as a
(n lines, xy data) array
kushalkolar commented on Oct 25, 2024 Also getting rid of all the graphic features in CollectionProperties which affect each individual graphic.
In essence, graphic features for a collection should only affect things at the collection-level. If a user wants to affect an individual graphic they should index that one graphic or iterate through the graphics.
Likewise for events, event handlers can be added to the collection, at the collection level, they do not get added to all the individual graphics in the collection.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|