Masonry: Request layout does not implicitly start a redraw

[DJMcNab]

If, when responding to an event, you change state which will be updated in layout, the way you have to handle that is:

ctx.request_layout();
ctx.request_paint();

e.g.

xilem/crates/masonry/src/widget/textbox.rs

Lines 182 to 184 in aaeeadb

	// We might have changed text colours, so we need to re-request a layout
	ctx.request_layout();
	ctx.request_paint();

Otherwise, the update does not actually get drawn. This is not very ergonomic, and is a significant footgun in the masonry layer that this does not happen. We need to find a solution here. That might just be that request_layout also requests a paint; this should be at the right level in the passes

[Philipp-M]

Maybe we can request a paint, when the layout pass needs it? So that when layout doesn't change anything that requires a repaint, we can save a paint pass? But maybe this is also too much of a footgun, and a layout request should just imply a paint request.

[DJMcNab]

That's a subtly different question, I think. This is about scheduling a layout to actually happen. Currently, that is the next time a paint is requested, because only needs_paint sends Winit a redraw requested command - handling that is when the layout/paint pass actually happens

[Philipp-M]

Yeah probably a subtly different question. I do think though, it's not necessarily a footgun when we have a good testsuite. One just needs to remember what may really have changed and request all the passes that are necessary for that. And when one of the passes requires a further pass, that should be reflected in that pass.

I just checked, currently at least a layout pass implies a repaint:

xilem/crates/masonry/src/widget/widget_pod.rs

Lines 848 to 849 in aaeeadb

	// TODO - Not everything that has been re-laid out needs to be repainted.
	self.state.needs_paint = true;

But when checking e.g.

xilem/crates/masonry/src/widget/image.rs

Lines 59 to 64 in aaeeadb

	/// Set new `ImageBuf`.
	#[inline]
	pub fn set_image_data(&mut self, image_data: ImageBuf) {
	self.widget.image_data = image_data;
	self.ctx.request_layout();
	}

this could indeed be a footgun, when the TODO would be resolved and the image dimensions haven't changed in a new ImageBuf...