You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently all of our style props are passed inline to any given view component during each render pass. This works fine, but I suspect we'll gain a lot in terms of performance by switching to a stylesheet API. The goal here is that instead of writing our styles as we have been, we will instead write:
During the creation of a StyleSheet with StyleSheet.create we can immediately marshal all the style properties over to native where we can hold onto a large std::map<StyleSheetId, std::map<std::string, juce::var>> which maps a stylesheet ID to a map of key/value style props on the native side.
StyleSheet.create fills a new entry in this map and returns to javascript a map of of the IDs we created to reference these things, so that subsequently writing styles.container in javascript evaluates to the right styleSheetID for lookup in that map.
Now, during a render pass, we only have to pass a single style property for each View, and inside View::setProperty we can lookup the corresponding stylesheet props and update the target view in bulk, then repaint once.
In the end, this will drastically reduce the number of props going over the native boundary during each render pass, drastically reduce the number of repaint() calls triggered, and help us cache previously painted views (if we see a new style property that matches the one I already have, no need to bulk update, no need to repaint).
I want to also mention here the discussion we had in #217: #217 (comment). This discussion is about using props.getWithDefault on the native side. Generally I suspect we'll still lean on props.getWithDefault within our setProperty overrides because we always want to render something if we can. But with the atomic/bulk stylesheet updates we can more safely assume that during a styles update, all default style properties are indeed set by the time we care about them. Currently I'm not sure exactly how much that will change the way we write this type of code, but it's worth mentioning.
The text was updated successfully, but these errors were encountered:
This issue is for supporting a styles API similar to React Native's StyleSheet: http://reactnative.dev/docs/stylesheet
Currently all of our style props are passed inline to any given view component during each render pass. This works fine, but I suspect we'll gain a lot in terms of performance by switching to a stylesheet API. The goal here is that instead of writing our styles as we have been, we will instead write:
This is a subtle change, but the point is this:
StyleSheet.create
we can immediately marshal all the style properties over to native where we can hold onto a largestd::map<StyleSheetId, std::map<std::string, juce::var>>
which maps a stylesheet ID to a map of key/value style props on the native side.StyleSheet.create
fills a new entry in this map and returns to javascript a map of of the IDs we created to reference these things, so that subsequently writingstyles.container
in javascript evaluates to the right styleSheetID for lookup in that map.View::setProperty
we can lookup the corresponding stylesheet props and update the target view in bulk, then repaint once.I want to also mention here the discussion we had in #217: #217 (comment). This discussion is about using
props.getWithDefault
on the native side. Generally I suspect we'll still lean onprops.getWithDefault
within oursetProperty
overrides because we always want to render something if we can. But with the atomic/bulk stylesheet updates we can more safely assume that during a styles update, all default style properties are indeed set by the time we care about them. Currently I'm not sure exactly how much that will change the way we write this type of code, but it's worth mentioning.The text was updated successfully, but these errors were encountered: