custom attachments

[brandon-reinhart]

In progress PR adding the ability to create custom attachments that can be assigned to slots.

May optionally include the ability to create custom attachment loaders.

[brandon-reinhart]

I am working on the interface to modify a region attachment after it has been created. The region attachment can be empty upon creation, but to render any visible contents, the user needs to set all fields and call update_region. This should be clear and not something you can mess up.

[brandon-reinhart]

spSlot_setAttachment: It appears that setting the attachment on the slot does not increment the attachment ref count.

This seems strange to me, as the pointer is in use and if an attachment is set on a skin the ref count is incremented. It seems to me that an attachment that is in use by a slot should have its refcount increment and dispose called when it is no longer in use, but spine c does not do this.

As a result, it is possible to set an attachment on a slot and then drop the attachment, causing an access violation.

[brandon-reinhart]

Another issue I am investigating is that calling Slot::set_attachment cause an immediate panic. Calling the underlying c::spSlot_setAttachment works fine.

Edit: This is due to the non-incrementing ref count. If the refcount is incremented by spSlot_setAttachment, Slot::set_attachment is reliable.

[brandon-reinhart]

ref: EsotericSoftware/spine-runtimes#2399
ref: EsotericSoftware/spine-runtimes#2398

[brandon-reinhart]

An alternative to making attachment accessors mutable is to place the create attachment convenience function in RegionAttachment and have it take the loader and props as arguments.

[brandon-reinhart]

Example of the current code:

        let attachment_loader = AttachmentLoader::new_atlas_loader(&atlas);

        let region_props = RegionProps {
            x: 0.0,
            y: 0.0,
            scale_x: 1.0,
            scale_y: 1.0,
            rotation: 0.0,
            width: 128.0,
            height: 128.0,
            color: Color::new_rgba(1.0, 1.0, 1.0, 1.0),
        };

        let attachment = attachment_loader
            .create_region_attachment(None, "test", "head", &region_props)
            .unwrap();

        unsafe {
            let mut slot = controller.skeleton.find_slot_mut("front-shin").unwrap();
            slot.set_attachment(Some(attachment.clone()));
        }

[jabuwu]

Nice work.

spSlot_setAttachment: It appears that setting the attachment on the slot does not increment the attachment ref count.

We shouldn't be making modifications directly to spine_c.rs, since it's auto-generated. We will need to wait for a response to the Spine C PRs.

[jabuwu]

I realize it's an exceedingly rare case, but I think we should bubble up the error here, wrapped in SpineError::NulError.

[jabuwu]

Suggested change

	/// Check error1() and error2() for more information.
	/// Check [`error1`](`Self::error1`) and [`error2`](`Self::error2`) for more information.

[brandon-reinhart]

Nice work.

spSlot_setAttachment: It appears that setting the attachment on the slot does not increment the attachment ref count.

We shouldn't be making modifications directly to spine_c.rs, since it's auto-generated. We will need to wait for a response to the Spine C PRs.

Yeah, that's why I noted this is temporary. The goal of this was to prove out it resolves the problems, which it does in my testing.

[brandon-reinhart]

This is all usable. Anything else I should do here? It doesn't require any changes from the spine runtime.

[brandon-reinhart]

Ship it!