Add gfx::RectT slicing methods

[martincapello]

I need these methods to implement aseprite/aseprite#4533

I have also added tests for them.

I'm not sure if you @dacap want this to be added here in laf. So let me know if you think I should move them to some aseprite utilities methods.

Maybe we can keep the sliceV and sliceH methods and move the nineSlice method. Idk whatever you say is okay.

[aseprite-bot]

clang-tidy review says "All clean, LGTM! 👍"

[dacap]

@martincapello in which way these methods are used? probably a gfx::Region can be used in this case/to calculate the rectangles (because we can subtract the center from the gfx::Region and get each band.

[martincapello]

I'm using the nineSlice method to split Aseprite's 9-slices to get each rect that I have to use to split the image under the each part of the 9-slice slice. Also, I need it to split the 9-slice bounds while the user is modifying its center/size, so I can use each rect to scale each part of the original image according to the new size of each slice's part.

[martincapello]

I think that maybe I could try to use a gfx::Region...I'm not sure how convenient it would be, but I can try if you want.

[dacap]

As I don't have the code at hand I cannot decide what is best for your case.

In case Region is not useful for your case, and you need these functions, I'd change the API to make all these functions const and return *this, the result could go to the parameters (as an array as in nineSlice() or as a couple of references, you could specify the same instance in one of the outputs too, but it's the API client decision).

nineSlice() can return *this too (remember to pass const RectT<T>& center).

[martincapello]

As I don't have the code at hand I cannot decide what is best for your case.

I will push it soon.

In case Region is not useful for your case, and you need these functions, I'd change the API to make all these functions const and return *this, the result could go to the parameters (as an array as in nineSlice() or as a couple of references, you could specify the same instance in one of the outputs too, but it's the API client decision).

I have been playing around with https://fiddle.skia.org/ and trying the difference operator to subtract the center rect from a region...and it seems that it would not fit my case very well (it would make the code more complex actually). Alright, I will update the API. Also we can just move this to Aseprite if you are not sure that they belong to Laf. Mostly because nineSlice seems too specific to my use case...the sliceV and sliceH feels more generic or primitive...

nineSlice() can return *this too (remember to pass const RectT<T>& center).

Oh yeah, missed that one, thanks.

[aseprite-bot]

clang-tidy review says "All clean, LGTM! 👍"

[aseprite-bot]

clang-tidy review says "All clean, LGTM! 👍"

[aseprite-bot]

clang-tidy review says "All clean, LGTM! 👍"

[martincapello]

I have just pushed a commit with my use case: aseprite/aseprite@de6b337

These are the lines where I use the nineSlice method:
aseprite/aseprite@de6b337#diff-e66935e4a665ab106a0d98b3930cd991e1de3e678b95e03e506ed880f484de86R117
aseprite/aseprite@de6b337#diff-e66935e4a665ab106a0d98b3930cd991e1de3e678b95e03e506ed880f484de86R132
aseprite/aseprite@de6b337#diff-e66935e4a665ab106a0d98b3930cd991e1de3e678b95e03e506ed880f484de86R144

[dacap]

I'll revert this commit force pushing laf beta, this commit should have gone to the main branch.