wgpu surface unnecessasrily recreated every frame

[nebneb0703]

iced_layershell performs a wgpu surface reconfigure event at the start of every frame, even if the surface size has not changed:

exwlshelleventloop/iced_layershell/src/application.rs

Lines 401 to 420 in 76a9c0c

	IcedLayerEvent::RequestRefresh {
	width,
	height,
	fractal_scale,
	} => {
	state.update_view_port(width, height, fractal_scale);
	let logical_size = state.logical_size();
	debug.layout_started();
	user_interface = ManuallyDrop::new(
	ManuallyDrop::into_inner(user_interface).relayout(logical_size, &mut renderer),
	);
	debug.layout_finished();
	let physical_size = state.physical_size();
	compositor.configure_surface(
	&mut surface,
	physical_size.width,
	physical_size.height,
	);

this often takes up a whole frame to complete (vsync?), and corresponds to unnecessary CPU time

i tried a naive fix to avoid the code path, but it broke the actual rendering, which randomly took up to several frames to present the surface, hence i am not submitting a PR.

i used samply to obtain measurements and profiling. it's possible this process may be introducing bias i am unaware of.

[Decodetalkers]

can you confirm if it is fixed in the new commit? I think I have fixed it

[nebneb0703]

it now draws much less often, but still reconfigures the surface for every drawn frame.

additionally, on-hover events are now broken, as the iced ui only receives updates on click or from subscribers

[Decodetalkers]

it now draws much less often, but still reconfigures the surface for every drawn frame.

additionally, on-hover events are now broken, as the iced ui only receives updates on click or from subscribers

what do you mean by on-hover events are now broken.. seems it all fine on my example.. The redraw only will happen if there is new message or ui_state is changed. it should not be every drawn frame. or you are using backend mode?

[nebneb0703]

The counter example has a subscription for all iced/window events, which run in a separate thread:

exwlshelleventloop/iced_examples/counter/src/main.rs

Lines 76 to 78 in e005014

	fn subscription(&self) -> iced::Subscription<Self::Message> {
	event::listen().map(Message::IcedEvent)
	}

This includes mouse movement events.

These are only used to debug log:

exwlshelleventloop/iced_examples/counter/src/main.rs

Lines 82 to 85 in e005014

	Message::IcedEvent(event) => {
	println!("hello {event:?}");
	Command::none()
	}

Removing the subscription demonstrates the hover issue, which only appears after the latest commit

[nebneb0703]

This behaviour can be considered an iced bug. In the latest release of iced, button status is checked in draw not update:

https://github.com/iced-rs/iced/blob/9bfbd7cda79aceef2d115b8bb35e8f3257dcabf2/widget/src/button.rs#L356-L368

This is fixed in PR iced-rs/iced#2662, where it moves to update:

https://github.com/iced-rs/iced/blob/28ec6df8f0ebf96966bee61caf5a325695314b7a/widget/src/button.rs#L343-L355

Edit: Prior to the merging of iced-rs/iced#2662, it may be required by iced to draw every frame unconditionally, hence the fix to only draw when the ui state has changed is invalid for earlier versions of iced.

[Decodetalkers]

This behaviour can be considered an iced bug. In the latest release of iced, button status is checked in draw not update:

https://github.com/iced-rs/iced/blob/9bfbd7cda79aceef2d115b8bb35e8f3257dcabf2/widget/src/button.rs#L356-L368

This is fixed in PR iced-rs/iced#2662, where it moves to update:

https://github.com/iced-rs/iced/blob/28ec6df8f0ebf96966bee61caf5a325695314b7a/widget/src/button.rs#L343-L355

Edit: Prior to the merging of iced-rs/iced#2662, it may be required by iced to draw every frame unconditionally, hence the fix to only draw when the ui state has changed is invalid for earlier versions of iced.

I see.. maybe I should revert this fix.. it induced many problems

[Decodetalkers]

I have read the code in iced.. maybe I should wait for new iced being published, then solve this problem