Comments (8)
Thanks for the idea!
Yes, I think this is a basic use case we should satisfy. However, it's not as straightforward as it may seem.
The main challenge here is to avoid decompressing and uploading the image data to the GPU every time we draw. In other words, we need to keep track of the image somehow.
The current renderer uses the path
of an Image
as the identifier and lazily loads its data on the first draw (this should probably happen in another thread eventually). Then, the renderer keeps a cache that connects each image path with a texture on the GPU. Currently, this cache is never trimmed (if you use a lot of images, you will run out of video memory eventually).
I think we could leverage guillotiere
to create texture atlases for images and invalidate parts of them efficiently. This is most likely not an easy task and not completely necessary to implement the feature of this issue, but I wanted to mention it in case anyone feels like going on a journey!
For now, a way to implement this would be to attach a unique id together with the image bytes and use that as a key in the renderer cache. A way to make this explicit would be with an opaque image::Data
type or similar:
const EMBEDDED_IMAGE: image::Data = image::Data::from_bytes(
"my_id",
include_bytes!("image.png"),
);
const FILE_IMAGE: image::Data = image::Data::from_path("resources/ferris.png");
However, I am not a fan of using stringified global identifiers, as they open the door for many pesky bugs (think what would happen if an identifier is used twice with different bytes).
Overall, I think the problem is telling us that an Image
widget is not the best approach for this. I have the feeling a Canvas
widget/abstraction will be able to satisfy these needs better.
What are your thoughts?
from iced.
My use case is for fractal art and other procedural art, where there never was an "original image" and it's all procedurally generated. Having a GUI library for procedural art would be amazing, because a lot of procedural art is fiddling with settings. Right now I do that via command line arguments, but it would be great if I could use checkboxes, type numbers into fields, etc and get realtime updates.
There are a few tiers of features I can think of that would make my life easier, ordered from least work to most work.
- An API to use raw RGBA8 bytes as an image. This would let me click a button, compute the procedural data on a background thread or with rayon, then pass the result to the GUI once it's done
- An API to apply an arbitrary fragment shader alongside the image, plus arbitrary uniforms. Procedural art usually involves 2 separate steps. The first is a long-running computation, and the second is code that convers the results of that computation into some sort of visualization. If I could use visualization settings to drive some shader uniforms, I could write all the visualization code in a shader, letting me get real-time changes in visualization. I'm imaging dragging a slider back and forth and being able to see updates as I drag. Rayon could theoretically handle something like this for small images, but with shaders I could do something like supersample an 8k image, etc
- Render targets. Some fractals, like the mandelbrot set, or the abelian sandpile fractal can themselves be computed by fragment shaders that output to an R32 render target. If I could compute these by bouncing them back and forth between 2 render targets, I could completely eliminate the "long-running computation" I mentioned earlier.
- Readback of render targets. The ultimate goal of procedural art is to share the results with others, and being able to pull data out of a render target and pass it to something like piston::Image to save would let me do that.
It sounds like you're already open to #1, and #2 doesn't seem too crazy imo. I have no idea how much work #3 and #4 would take.
from iced.
This will allow to include the image bytes in an executable binary or load it manually.
Or generate it procedurally.
from iced.
As for "Canvas" widget, It's a great idea for both image and mesh data. Do you have any plan for that?
@piaoger Yes! A Canvas
widget is in the roadmap. The related issue is #32.
why not use some quick hash on the image bytes as the cache identifier?
@bingo347 I think that could work. We will need to make image::Data
own the bytes instead of a reference. This will make it clearer to users that you are supposed to keep it as part of the application state while also satisfying other use cases (like storing remote image data). I will try to play with this and see if it works out well.
Right now I do that via command line arguments, but it would be great if I could use checkboxes, type numbers into fields, etc and get realtime updates.
@ejmahler This reminds me a lot of the mesh
example I made in Coffee. Of course, you can hardly call that art, but the idea would be the same: a GUI driving a graphics engine.
I think all the features you list, besides maybe the first one, are meant to be satisfied by some kind of canvas widget that exposes an advanced graphics API for drawing. A widget that would only be available in GPU-accelerated renderers.
I think #32 (or a similar custom widget) should satisfy your use cases in the long run. You seem to be way more experienced than me with graphics programming and I'd love to hear any suggestions you may have about a possible API and its implementation, while learning more about your use cases.
from iced.
I’ve also wanted this feature and wouldn’t mind implementing. Feel free to assign the task to me.
from iced.
I also want something like Image::from_bytes before. My case is providing a remote url as path, and the image will be downloaded and loaded ..
As for "Canvas" widget, It's a great idea for both image and mesh data. Do you have any plan for that?
from iced.
@hecrj why not use some quick hash on the image bytes as the cache identifier?
Canvas widget Is good idea for dynamically changing images, but for static images I like the idea with image::Data type
from iced.
I have opened #90, which should satisfy some of the use cases discussed here. Let me know what you think.
@ejmahler Would you also be interested in an image::Handle::from_pixmap
method?
from iced.
Related Issues (20)
- Crash on raspberry pi when using wgpu feature
- Container shadows are inconsistent between `wgpu` and `tiny-skia` with custom theme HOT 2
- Dynamic Window Size HOT 2
- Running the example from README.md: "cannot find function `run` in crate `iced`" HOT 4
- Input widget should not copy or cut if secure
- Scrollable content remains at the top of a scrollable
- My text() os not updated when clicking Theo button in FydeOS 18.0 HOT 3
- Pane Grid `PickList` does not work when `Responsive` is present in Pane's controls
- 0.12.1 Failing to compile when included as dependency HOT 1
- Cannot use mousewheel without shift to scoll a horizontal-only scrollable. HOT 2
- Problem rendering texts in PopOS 22.04
- GLIBC_2.29 not found in Deepin 20.9 HOT 1
- Application does not start on Windows 10 pro 64 bits HOT 2
- Shell opens along with the iced application in Windows 11 Pro HOT 2
- TextInput value overflow with tiny-skia backend
- web-sys dependecy resolution HOT 1
- image ferris cannot be loaded in tour example under wasm target
- MouseArea does not report mouse wheel events.
- Nix shell expression out of date in `DEPENDENCIES.md` HOT 1
- Nested scrollable behaviour
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from iced.