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
If a component hasn't changed (see #72, which this probably depends on), then we know that the paints of the elements bounded by that component haven't changed either.
There is one other thing (other than state changes) that can break this cache: terminal resize events!
It seems like the cache needs to live in the shadow tree - I think it is one node per element now, not per component, so that should be straightforward.
Not quite sure how to get this information to the painter. Right now it takes a concrete element tree. Should it be inside that data structure, or somehow adjacent? I guess we could use id() as a cache key, since if we have Granular state changes #72 we'd be caching the actual produced element instances.
Now that I'm thinking about it, its a little odd to cache at this layer but not at the previous layer (layout). Caching layout is a little tricky because elements can potentially take imperative actions on their parent's layout... does that break this idea? Need to be careful here.
The text was updated successfully, but these errors were encountered:
If a component hasn't changed (see #72, which this probably depends on), then we know that the paints of the elements bounded by that component haven't changed either.
id()
as a cache key, since if we have Granular state changes #72 we'd be caching the actual produced element instances.The text was updated successfully, but these errors were encountered: