Allow `Adapt` message handlers to access `inner`?

[Kwarrtz]

Is there a reason that the handler of Adapt::on_messages is not given access to the inner widget like for other widget types (even including other adapters like Map)?

My specific use case is that I'm trying to create a Sprite which tracks its own ImageHandle in an Adapt and can re-allocate in response to a message, which requires the handler to have access to both the underlying Sprite (to call set) and the state of the Adapt, but this seems like a problematic limitation any time you're working with a widget that can be dynamically modified.

[dhardy]

It's possible: #627.

But is this even the best solution for your issue? Image is an adapter over Sprite; it may make sense to use a custom widget in the same way. What are you trying to do exactly, just make something which is a bit easier to use with an ImageHandle?

[Kwarrtz]

I have an image that I'm updating periodically with new data generated in a background thread. That thread sends a message back to the Sprite through a Proxy, where the handler uploads the new image and, if it changed size, re-allocates and updates the ImageHandle as well.

Right now I'm storing the ImageHandle in the top-level AppData and am updating it by message-passing, but this has some drawbacks. For one, the Sprite's message handler not having mutable access to the ImageHandle means it can't take the old one to pass it to DrawShared::image_free, and I can't do that in the top-level handler either because it doesn't have access to an EventCx. (I guess the AppData handler could pass the old handle in yet another message back to the Sprite, which could make the actual free call, but that's getting a bit clumsy to my mind.) I'm also having some issues which I thought might be coming from delays in the message handling leading to synchronization problems, but that's just a guess at the moment.

So that's why I was looking at storing the ImageHandle with .with_state and mutating it directly, since it's the only widget that actually needs it, but for that I'd need to be able to access the Sprite from the message handler. One pattern I thought about (that I guess would work for most stateful widgets?) is to update the ImageHandle in the Adapt handler and then call Sprite::set within an .on_update handler for the internal Sprite (or rather the MapAny between the Sprite and the Adapt I guess), but that also doesn't work here because set needs an EventCx, not just a ConfigureCx.

Would a custom widget be your suggestion here? That seemed a bit overkill to me, but this is admittedly a somewhat specific use case.

[Kwarrtz]

Sprite having a method that returned (a reference to?) its internal ImageHandle would also solve this issue for me. Then I wouldn't have to store the ImageHandle myself anywhere at all.

EDIT: This seems useful independent of the original question raised here, so I opened a new issue (#629) for it.

[dhardy]

So, like the Canvas and Svg widgets? Canvas should maybe be renamed to TinySkiaCanvas. It sounds like you want some variant with a different drawing API (maybe just a sRGB buffer).

A ConfigCx could in theory be extended to allow access to shared (draw) state, enabling Sprite::set to support a ConfigCx, but this seems unnecessary.

Would a custom widget be your suggestion here? That seemed a bit overkill to me

Sprite is designed primarily to be a component of other widgets (like Image), so yes.

Both Canvas and Svg require state management: start drawing from set_rect if not already drawing and check whether a redraw is required when receiving the result. Since there isn't an on_set_rect handler you can't do this correctly without a custom widget.

I'm wondering if there should be a standard library widget for this (maybe kas::image::Buffer with an on_resize callback). I could make one, but it help if you could provide some example code to draw an image.

You mention using a background thread to update the image; what does your code send between threads? Canvas sends both the CanvasProgram and Pixmap to avoid requiring these be Sync or Clone while Svg clones the source data.

[Kwarrtz]

The image generation is based on iterated function systems. The "chaos game" runs continuously on the background thread. Every fixed number of iterations the refined image is written to a raw RGBA Arc<Mutex<Vec<u8>>> buffer shared with the main thread and a message is sent via a Proxy which triggers the handler on the Sprite to upload the new data. The only other thing sent between the threads are the parameters of the IFS as specified by the user through the UI; they're sent over a channel to the background thread whenever they change. One of those parameters is the dimensions of the generated image, and changes to that are what triggers a reallocation through DrawShared, not UI resizing or a redraw request or anything like that. I can link the repository if you think the details are relevant.

Maybe Canvas would be a better fit for what I'm trying to do? That API and its intended use case were a bit opaque to me. If there were to be an ideal pre-built widget for my use case, I guess it would be an image with some built-in rescaling behavior and a method to write a raw buffer to it (which could just be an RGBA &[u8] plus dimensions or something with a more structured API). It would end up being a fairly thin wrapper around Sprite as it's currently implemented, I think.

[dhardy]

Fixed in #627.