Unnecessary UserInterface::draw?

[kaimast]

Hi,

I am wondering whether this line in the example is correct:

https://github.com/hecrj/iced/blob/4d3afe2f0c6d42bb86248c1dbf5c5188e2b9e9ba/examples/integration/src/main.rs#L150

Why do I need to call draw even when the user_interface has not changed?

[kaimast]

Oh I guess there could be some events, like resize, that don't get passed on to messages. If that's the case then maybe UserInterface::update should return some information on whether any state was changed?

[hecrj]

If that's the case then maybe UserInterface::update should return some information on whether any state was changed?

Yes, this is something I have in mind! But I am waiting to see how other important parts related to event processing shape up (like layers and event capturing).

We are also calling view more times than necessary, as the Application widget tree should only be able to change after an update.

There is quite a bit of room for improvement when it comes to optimization (lazy widgets!), but I believe the complexity tradeoff is not worth it right now. At this stage, we want to keep things simple and be able to try different ideas easily.

[kaimast]

Yeah that makes sense. Feel free to close this.

[TianyiShi2001]

(related to #30 and #579)

Are you aware of the crate cursive which is used to build text-user interface (TUI)? It supports layers and it redraws only upon registered event (and it has rules to determine which layer will consume the event). I guess it would be helpful to use cursive as a reference when implementing these features.

IMHO these features are really fundamental and are also likely to break a lot of existing code so they should be dealt with as soon as possible.

[kaimast]

I think the wgpu/opengl integration has changed sufficiently for this to be closed.

There still be unnecessary redraws internally but they are not exposed to the user directly anymore.