Reduce the memory footprint of wide tile commands

[LaurenzV]

This PR reduces the memory footprint of wide tile commands from 48 bytes to 16 bytes. This is achieved by introducing a number of changes:

• For fill/alpha fills, we store the core properties (paint, mask, etc.) in a separate buffer that is built on a per-path basis, and the commands now simply contain an index that allows us to fetch the properties once we need them without having to duplicate them in each command.
• A similar pattern is used for clip commands.
• Clip commands now use u16 instead of u32 for x/width.
• Instead of storing the alpha index as a usize, we store an absolute offset on a per-path basis, and each command only stores the relative offset to the index of the path it belongs to. By doing so, using u32 for each command to store the alpha index is sufficiently large.

This leads to some nice speedups in many cases:

[grebmeg]

Hey @LaurenzV, awesome work! I’m adding myself as a reviewer to indicate that I plan to review the PR, but I’ll likely be able to get to it on Monday. 🙏

[grebmeg]

[nit] Props feels a bit generic to me. Would a more specific name better reflect its purpose? Maybe something like:

pub struct CmdAttrs {
    pub fill: Vec<FillAttrs>,
    pub clip: Vec<ClipAttrs>,
}

[grebmeg]

If I’m calculating the struct size correctly, it’s now 32 bytes instead of 24 bytes in single-threaded mode, so we’re paying an additional 8 bytes even though this field isn’t used there. While we probably won’t have thousands of clips simultaneously, would it still make sense to keep this behind a feature gate?

[grebmeg]

[nit] Since this runs inside the loop, could we avoid casting to u32 here and instead cast alpha_base_idx to usize when creating FillProps above?

[grebmeg]

I think this would require updating my image optimization #1327. I’d probably need to return an enum here so I can decide which path to take when generating fill commands. I’ll sort that out in my PR, but for now maybe something like this:

Suggested change

	let override_color =
	if let Paint::Solid(s) = &self.props.fill[props_idx as usize].paint {
	if s.is_opaque() && self.props.fill[props_idx as usize].mask.is_none() {
	Some(*s)
	} else {
	None
	}
	} else {
	// TODO: Implement for indexed paints.
	None
	};
	let fill_props = &self.props.fill[props_idx as usize];
	let override_color = match &fill_props.paint {
	Paint::Solid(s) if s.is_opaque() && fill_props.mask.is_none() => Some(*s),
	_ => None,
	};

[grebmeg]

Could we early-return when there are no strips, similar to generate?

Suggested change

	let (clip_props_idx, alpha_base_idx) = if n_strips > 0 {
	let alpha_base_idx = strips[0].alpha_idx() as usize;
	let props_idx = self.props.clip.len() as u32;
	self.props.clip.push(ClipProps {
	thread_idx,
	alpha_base_idx,
	});
	(props_idx, alpha_base_idx)
	} else {
	// In case we have 0 strips, those variables won't be accessed
	// anyway.
	(u32::MAX, usize::MAX)
	};
	if n_strips == 0 {
	return;
	}
	let alpha_base_idx = strips[0].alpha_idx() as usize;
	let clip_props_idx = self.props.clip.len() as u32;
	self.props.clip.push(ClipProps {
	thread_idx,
	alpha_base_idx,
	});

[grebmeg]

The same with casting u32 here

[grebmeg]

Would it make sense to shrink usize to u32 here?

[grebmeg]

Just an idea: Paint is 24 bytes, so what if we stored solid PremulColor values as indexed paints? Could that give us any performance benefits? Maybe we can store it as paint_idx: u32 reducing the size from 24 bytes down to 4 bytes?

[grebmeg]

This looks like a repeated pattern, so if it makes sense, maybe we could add col_idx method next to alpha_idx?

[grebmeg]

Would it make sense to assign reasonable starting capacities for vectors in Props, specifically for FillProps? I think we can assume it will need to grow during the first render since it’s the primary data-holding structure. It might also be worth checking whether this shows any impact in benchmarks.