Experimenting with Iced - Built Minesweeper Game - Simple but Inefficient?

[veniamin-ilmer]

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

This might be a nice example to add into iced...

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

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

This bugged me a bit. I looked around, and found this: #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 Iced 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.

I see in #553 there is talk of a widget_key, but I am unclear how this can be accomplished while still keeping all widgets stateless.

Am I missing something?

[hecrj]

On the other hand, I can't help but see how inefficient it seems.

Is it, though? Have you measured anything?

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

view is rarely the bottleneck of an application. Building a widget has no considerable cost.

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 Iced 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.

We already have a persistent widget state tree and a persistent primitive tree. The former is diffed using a one-pass algorithm similar to React's reconciliation. The latter can be used for interesting things like incremental rendering, which is implemented as a PoC for the new iced_tiny_skia renderer (see #1811).

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

I see you used a bunch of columns, rows, and buttons... However, using a Canvas would be a better approach. The game_of_life example uses a Canvas to render an infinite grid.

[veniamin-ilmer]

Thank you for this explanation.

Just so I can better understand how incremental rendering works, I see that Button comes with a method on_press_maybe. I am a bit confused regarding the purpose of this method.

Would Iced be better at optimizing this code?:

button("hi").on_press_maybe(if some_condition { Some(Message::pressed) } else { None });

vs this?:

if some_condition {
  button("hi").on_press(Message::pressed);
} else {
  button("hi")
}

[veniamin-ilmer]

Thank you for switching to tiny-skia btw.

My little minesweeper game's RAM use went down from 80 MB to only 4 MB.

The executable size went down from about 8 MB to 2.5 MB