Before this change, the image asset (which may contain multiple reps
of an image for differing traits) was only consulted when the trait
collection changed. But in cases where display was scheduled
on the node and the trait collection had not changed, the image node
ends up with the default representation instead.
An example of this:
You have an image asset with two versions: light (default) and dark.
The device is currently in dark mode
The image is being presented in an item in a collection node.
Item node is first added to hierarchy. Trait collection doesn't match
so regenerateFromImageAsset=true.
Dark image is rendered, as expected
Item node is scrolled off screen
Item is scrolled back on screen
This triggers display on the item node
Trait collection has NOT changed so regenerateFromImageAsset=false
So, imageAsset is not consulted and default (Light) image is rendered
After looking at this a lot, I don’t see any reason why we need the
regenerateFromImageAsset flag at all (introduced in #1663). Whenever
the image node is displayed we need to make sure we are generating the
correct representation.
Before this change, the image asset (which may contain multiple reps of an image for differing traits) was only consulted when the trait collection changed. But in cases where display was scheduled on the node and the trait collection had not changed, the image node ends up with the default representation instead.
An example of this:
You have an image asset with two versions: light (default) and dark. The device is currently in dark mode The image is being presented in an item in a collection node.
After looking at this a lot, I don’t see any reason why we need the regenerateFromImageAsset flag at all (introduced in #1663). Whenever the image node is displayed we need to make sure we are generating the correct representation.