Just about everything in Royale is the way it is because it was the fastest way
to get someone's app working. Not only is there a PAYG (pay-as-you-go)
philosophy, there is a DAYG (do-as-you-go) philosophy. We didn't have enough
folks committing code to optimize or emulate all Flex code paths.
For the apps I worked on, they rarely called getStyle, so there wasn't a need
to emulate the old Flex lookup. Also, it seemed better to steer those apps
away from using getStyle, especially for non-CSS-compliant styles. A Royale
app should perform best if the UI relies on CSS-compliant styles and no JS code
is thinking about styles. IMO, Royale doesn't have to emulate 100% of Flex, it
just has to emulate enough of Flex that Royale is the fastest path to migrating
a fast-enough app. Sometimes it is better to change your Flex app-code than
run on an emulation that is slow and/or fat.
So feel free to replace SimpleCSSStyles in MX and Spark application if you
want, but I suggest making sure you really have to have getStyle work in your
app or optimize how it works for a few scenarios where you have to have it.
HTH,
-Alex
On 1/2/21, 3:16 AM, "Edward Stangler" <estang...@bradmark.com> wrote:
What is the motivation of why style propagation is implemented
differently in Royale vs. Flex?
In Flex, UIComponent.getStyle() can look at materialized versions of the
inherited and non-inherited style values. It's quick. Propagation is
done through notifyStyleChangeInChildren(). (And that can be a
bottleneck in some cases; I've had to override
ViewStack.notifyStyleChangeInChildren() in Flex for performance, for
example.)
In Royale, UIComponent.getStyle() calls
ValuesManager.valuesImpl.getValue(). For
SimpleCSSValuesImpl.getValue(), that results in looping up the class
hierarchy (A extends B extends C etc.) and then recursive calls to
getValue() up the parent chain (A contains B contains C etc.),
potentially many levels. SimpleCSSValuesImpl.getValue() takes a
non-trivial amount time. And all this happens for each call to
UIComponent.getStyle().
In other words:
In Flex,
- getStyle() is usually cheap [O(1)],
- but style changes are expensive [O(size of tree)];
In Royale,
- getStyle() is probably expensive (at least in SimpleCSSValuesImpl up
many levels) [O(class hierarchy depth + longest paths in tree)],
- but style changes are cheap (presumably) [O(1) + event dispatches].
So this becomes a bottleneck in some parts of MX / Spark. For example,
during AdvancedDataGrid scrolling (after some other bigger bottlenecks
are eliminated), where some of the renderers (especially header
renderers) call getStyle() over and over and over again.
Before I go about trying to optimize some side of this, I just wanted to
understand why it's like this.
