This is a small optimization that should alleviate issues like #450 without hurting performance. I also feel like this will make the model slightly less confusing, as it took me a while to figure out what was going on. Certain resources, like object, listen to a few of their own specific properties, like sprite index, then repeat the update on their reference. That way the room editor knows to repaint objects with the new sprite.
The problem here was that per-property update sources were being used to implement this. This was extremely bloating the model in projects like #450 where there may be a hundred thousand instances and tiles. To clarify, every object in Java has a lock and the boxing makes them expensive to allocate. I realized that there is no actual difference here in using the single update source of the property map and using the per-property update sources. Not only in behavior, but also in terms of performance, it's just less memory consumption.
If we think about how such changes would be propagated this way, the way it was would mean that a change in any object's property would do a map lookup for the trigger source pair. Then it would signal the ObjectPropertyListener who would check the key and then fire the reference trigger. The way I have it now is that if any property is changed, it will signal the ObjectPropertyListener which still checks the key and fires the reference trigger. It's simply one less step in the loop, and doesn't change the performance since a map lookup is comparable to switching on an enum.
I agree it makes sense to keep the per-property sources for the UI so that components aren't getting informed of every other component's model changes. However, I still think they should be moved from the property map to the link factories so they don't continue to exist beyond the lifetime of a resource frame. I believe that the repeater listeners, like ObjectPropertyListener, should probably also be moved later on since they are prejudiced about what kind of model updates other editors and resources should respond to. I don't think that kind of business logic belongs in the domain classes.
This is a small optimization that should alleviate issues like #450 without hurting performance. I also feel like this will make the model slightly less confusing, as it took me a while to figure out what was going on. Certain resources, like object, listen to a few of their own specific properties, like sprite index, then repeat the update on their reference. That way the room editor knows to repaint objects with the new sprite.
The problem here was that per-property update sources were being used to implement this. This was extremely bloating the model in projects like #450 where there may be a hundred thousand instances and tiles. To clarify, every object in Java has a lock and the boxing makes them expensive to allocate. I realized that there is no actual difference here in using the single update source of the property map and using the per-property update sources. Not only in behavior, but also in terms of performance, it's just less memory consumption.
If we think about how such changes would be propagated this way, the way it was would mean that a change in any object's property would do a map lookup for the trigger source pair. Then it would signal the ObjectPropertyListener who would check the key and then fire the reference trigger. The way I have it now is that if any property is changed, it will signal the ObjectPropertyListener which still checks the key and fires the reference trigger. It's simply one less step in the loop, and doesn't change the performance since a map lookup is comparable to switching on an enum.
I agree it makes sense to keep the per-property sources for the UI so that components aren't getting informed of every other component's model changes. However, I still think they should be moved from the property map to the link factories so they don't continue to exist beyond the lifetime of a resource frame. I believe that the repeater listeners, like ObjectPropertyListener, should probably also be moved later on since they are prejudiced about what kind of model updates other editors and resources should respond to. I don't think that kind of business logic belongs in the domain classes.