-
Notifications
You must be signed in to change notification settings - Fork 568
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Image is no longer Send in 0.3.0 #1649
Comments
The semver checks are a very good idea! I recall when this made the rounds on Reddit. We should have tried to run it before the release :( With regards to the Image type: we’ve changed the implementation to use cross-platform image decoders and provide a backend-independent cache. As usual, this cache is thread local and that’s one thing that’ll make it harder. We could perhaps use send wrapper for the variants that aren’t send but I’m not sure this is the right path forward and it makes the Image type heavier. I think the approach of sending the shared pixel buffer and therefore a very concrete type is better than letting a very opaque type be send. I’d say it was send by accident. What do you think? |
Perhaps add something like this to the Image documentation could help?
|
Excellent! Can you make a PR or shall I? |
I can do that. |
Ran into this while trying to implement a demo app showing thumbnails in a list. I wanted to load the images in a background thread since loading them blocks the app otherwise. I obviously can't send path, and sending SharedPixelBuffer isn't ideal either - it requires you to implement caching, decoding yourself along with adjusting for any changes in view. It seems very limiting. |
Why is sending the SharedPixelBuffer not ideal? |
I already listed my reasons. If you go that route - you forego the convenience of letting your UI lib handle the format decoding, component resizing and caching. Loading the image in background is a fairly common use case with medium to large images, doing that should ideally be fairly straightforward. In QML, Image has an asynchronous property to help with that. |
The thing is that the Image uses internal caches that are thread-local. Overall, i'd say it would still be good if we can make Image Send again, and even try to offload all the image loading on a thread. |
@ansign If I do agree with Olivier that multi-threaded, asynchronous image decoding could (and should?) be a built-in feature of Slint itself, should not be something users have to do. API wise that would mean construction from a path, but we could also add the option of constructing a |
I would have been using path/url in my case, but a constructor with encoded data buffer is also a great idea. Since we cannot use a non-literal path in .slint's Image component directly; we have to pass slint::image object from rust code for all dynamically loaded images. This creates another issue when we need to pass a list of images from rust code to a .slint component. A non send Image means that you cannot create the final vec in the background thread, you have to create the slint::Image and the vec containing it in the GUI thread when you need to pass a list of images. I think in general, anything that is necessary (without alternate) to be passed to .slint files should be send for the sake of convenience. Asynchronous loading would be very nice too. |
Thanks. I agree. API wise it makes sense that |
This becomes even more clumsy when using dynamically loaded image content as a member of an exported An example could be found here: https://codeberg.org/moire/moire/src/commit/4cc53b1e37bcf09dd4929b5dddfd3825579a446b/crates/ui/src/tasklet.rs#L159 |
Maybe as single, all-embracing image type is not sufficient? Separation of concerns or another level of indirection has often served me well to resolve contradictory requirements. |
How about images as a property in a I don't consider this issue as resolved. Instructions on how to handle the |
Simple example: List with items that contain both an image and a text. |
Image now uses internal data structures that do not implement Send. This broke upgrading my application from 0.2.5 to 0.3.0 because I was generating an Image in a UI callback then moving it into an
upgrade_in_event_loop
callback. I hacked around this by passing aSharedPixelBuffer<Rgba8Pixel>
from the UI callback to the event loop then callingImage::from_rgba8_premultiplied
in the event loop.Perhaps cargo-semver-checks could have caught this.
The text was updated successfully, but these errors were encountered: