this post was submitted on 27 Jul 2023
20 points (95.5% liked)

Rust

5966 readers
31 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
 

I just attempted to write up a simple Minesweeper game with Iced. No bells or whistles, but it works:

https://github.com/veniamin-ilmer/minesweeper

On one hand, I find it pretty cool I built a clear cross platform GUI with actual functionality, within only 200 lines of code.

On the other hand, I can't help but see how inefficient it seems. If I ever need to modify any of the objects, I need to redraw all of them. The structure of the view method makes me think it is very difficult for Iced to maintain a "virtual DOM" to only make delta changes.

Am I wrong? Is there a more efficient way to do this in Iced?

Edit: I just found this - https://github.com/iced-rs/iced/pull/1284

As the library matures, the need for some kind of persistent widget data (see #553) between view calls becomes more apparent (e.g. incremental rendering, animations, accessibility, etc.).

If we are going to end up having persistent widget data anyways... There is no reason to have impure, stateful widgets anymore!

So it seems like Iced plans to have an internal "persistent widget storage", which in abstracted away from the user. But it is quite unclear to me how they would accomplish this, considering the view method doesn't provide an ID for any of its objects, so it would not be easy for Iced to determine the difference between updates.

you are viewing a single comment's thread
view the rest of the comments
[–] mmstick@lemmy.world 7 points 1 year ago* (last edited 1 year ago) (4 children)

As long as you store state in your application's struct so that there's no need to calculate and allocate in the view, then the view is quick to generate. You can also use lazy widgets that will avoid being re-recreated unless a given input has changed. Have you benchmarked to compare? You'd be surprised how efficient it is compared to heavier frameworks like GTK.

[–] van2z@programming.dev 1 points 1 year ago* (last edited 1 year ago) (1 children)

mmstick, it is always good to hear from you. You frequently provide a huge depth of knowledge in your comments.

I come from a windows background. If I want to make a memory efficient GUI, I always used native windows GUI libraries. All other frameworks have always seemed like they took up much more memory and CPU. This always annoyed me.

My little Minesweeper game is taking 78 MB of memory (with --release).

At the same time, Excel is only 2.5 MB, Notepad++ is only 1.9 MB.

Recently I found out that a lot of memory and CPU is used up simply to communicate with the GPU. I am confused about this.. Does Excel not use the GPU?

I am sorry, I feel like I am starting to rant here. This memory issue has been annoying me for a while, and I have not heard anyone provide a clear reason why these complicated apps seems to take up much less memory than any simple cross-compatible app I build.

[–] mmstick@lemmy.world 3 points 1 year ago

The application crashes when I start it, perhaps due to wgpu. After switching to iced = { git = "https://github.com/pop-os/iced" }, I'm able to run it and see 7.7 MB memory consumption. We use a software-based renderer by default. Keep in mind though that Windows also doesn't accurately report memory usage, and in Rust we have everything statically-linked into the binary. And there's a lot of stuff being embedded and cached in memory at the moment as these libraries are being developed.

load more comments (2 replies)