Created RectAtlas class for storing Pixmap and Texture Atlas Data

[deanljohnson]

Summary

Converted Pixmap and Texture to use a new RectAtlas class for storing atlas information instead of List<Rect>. See #697 .

Details

• Added new RectAtlas class
  • Implemented IList<Rect> so that it can be used in a similar fashion to the old implementation.
  • This should probably be removed in a future version of Duality as it doesn't add any real value, but that would be a breaking change right now.
  • Provides support for Vector2 pivots and string tags per index
  • 100% unit test coverage
• Pixmap slicer updated to provide editing support for pivots and tags.
• DynamicLighting and SmoothAnimation samples custom renderers updated to use pivots defined in the RectAtlas.

Kown Remaining Issues

• Samples have saved assets that are serialized with the previous List<Rect> implementation and therefore the Pixmaps have lost their data. This means we probably need to do two things:
  • Write in some kind of upgrade path where old serialization information is converted to the new form. Duality user code is going to have the same issues the samples do. I'm not sure how this has been handled in the past.
  • Update the assets stored with the samples to be serialized with the new data.
• In general I think this kind of change needs a pretty heavy amount of testing.

I did not implement 9-patch data storing in this PR. I think it could easily be added later on so I'd rather get this integrated/approved before we try to add more to this feature.

[ilexp]

Nice PR, good writeup too 👍

I did not implement 9-patch data storing in this PR. I think it could easily be added later on so I'd rather get this integrated/approved before we try to add more to this feature.

Agree completely. We can always add more later on, let's keep this one as concise as possible.

---

No review yet for time reasons, but here's a general roadmap for this PR:

1. Review and iterate on RectAtlas API and implementation.
2. Ensure backwards compatibility to make this a non-breaking change.
3. Review and iterate on integration into core, editor and samples.
4. Final testing, (squash-)merge, release.

Might take a bit, given the size of this PR, but we'll get there 🙂

[deanljohnson]

I agree with everything you've mentioned here and that is how I'd like to do it, but doesn't that make this a heavily breaking change since RectAtlas would not have an API similar to the previous List<Rect> implementation?

Changing from List<Rect> to using IList<Rect> is still technically a breaking change, but it is easily fixed by a breaking change by any users.

[ilexp]

I agree with everything you've mentioned here and that is how I'd like to do it, but doesn't that make this a heavily breaking change since RectAtlas would not have an API similar to the previous List<Rect> implementation?

Changing from List<Rect> to using IList<Rect> is still technically a breaking change, but it is easily fixed by a breaking change by any users.

That is a good point, but under the circumstances it doesn't matter: In a commonly used area like Pixmap / Texture atlas lookups, we should avoid breaking changes in both binary and source compatibility, unless we're on a major version step. RectAtlas replacing the old list of rects will be a binary breaking change either way - so how much it breaks the source doesn't matter going further.

Given that, my approach here would be to find a good design first, and then see how we can integrate it without breaking stuff. Fewer ties to old designs to worry about.

2. Ensure backwards compatibility to make this a non-breaking change.

As a preview of what I think could be doable here, we could

1. Replace atlas storage in Pixmap and Texture going from List<Rect> to RectAtlas, but keep the old API as-is.
2. Add new RectAtlas API (keep old) to Pixmap and Texture where old API used List<Rect>.
3. Flag the old API as [Obsolete].
4. Implement a SerializeErrorHandler in the compatibility plugin that is able to read the old List<Rect> fields in Pixmap and Texture resources and convert its data to the new RectAtlas field.
5. In the next major version step, remove the old [Obsolete] API and consider renaming the new API to something more fitting or concise now that the old API is out of the way. This last item is off limits for this issue, ignore for now.

If this approach can keep full compatibility, we're completely free in how we design RectAtlas at the cost of having to keep a bit of obsolete API until the next major version step.

[ilexp]

@deanljohnson What's the reason for closing this PR?