[AI Task] [Tizen.NUI.Components] Remove unrealizedItems temp list in Linear/GridLayouter scroll path

[JoonghyunCho]

Summary

Removes the temporary List<RecyclerViewItem> allocation and the O(N×M) RemoveAll(list.Contains) pattern from four scroll/range-removed sites in LinearLayouter and GridLayouter. The unrealize check is inlined directly into the RemoveAll predicate, giving a single O(N) pass with zero per-call allocation on the scroll hot path.

Changes

• src/Tizen.NUI.Components/Controls/RecyclerView/Layouter/LinearLayouter.cs
  • RequestLayout (line ~422): replaced foreach-into-temp-list + RemoveAll(list.Contains) with inline-predicate RemoveAll.
  • NotifyItemRangeRemoved (line ~1137): same replacement; the item.Index -= count shift is folded into the same predicate.
• src/Tizen.NUI.Components/Controls/RecyclerView/Layouter/GridLayouter.cs
  • RequestLayout (line ~419): same replacement.
  • NotifyItemRangeRemoved (line ~1032): same replacement.

Mode

Refactoring

Performance impact (per call)

Item	Before	After
List<> allocation	1 + backing array	0
RemoveAll predicate	O(N × M)	O(N)
Total passes over VisibleItems	2 (foreach + RemoveAll)	1

RequestLayout is called many times per second on scroll, so this directly removes per-frame Gen0 pressure on the recycler hot path.

API compatibility

• Public API signatures: unchanged.
• Behavior: unchanged. The predicate observes each element exactly once and performs the same unrealize + (in the range-removed path) the same Index -= count shift for items above the removed range.
• No native interop change.

Verification

• Build: passed (dotnet build src/Tizen.NUI.Components — 0 errors; pre-existing warnings unchanged).
• Tests: N/A (no unit tests cover these specific internal paths; behavior is preserved by construction).
• Benchmark: skipped (no sdb device available in this environment — manual on-device benchmark recommended).

Fixes #7608

[gemini-code-assist]

Code Review

This pull request optimizes the removal of invisible or removed items in GridLayouter and LinearLayouter by replacing temporary list allocations and O(N*M) lookups with the RemoveAll method. While this improves performance to O(N), the review highlights that the current implementation still incurs heap allocations due to closure captures in the lambdas. To achieve true zero allocation on these performance-critical paths, a manual iteration and shifting approach was suggested.

[gemini-code-assist]

While this change significantly improves performance by moving from O(N×M) to O(N), it doesn't strictly achieve "zero per-call allocation" as stated in the PR description. In C#, a lambda that captures local variables or this (which happens here via FirstVisible, LastVisible, and collectionView) results in a heap allocation for a closure object and a delegate instance on every call.

Since RequestLayout is on the scroll hot path, you could achieve true zero allocation by using a manual for loop to shift elements in-place, followed by a RemoveRange call. However, RemoveAll is much more idiomatic and readable, so this is only worth changing if absolute zero allocation is required for this performance-critical path.

[gemini-code-assist]

Similar to the change in GridLayouter, this RemoveAll call involves a closure allocation because the lambda captures state. To completely eliminate heap pressure on the scroll hot path, a manual iteration and shifting approach would be required. Given the PR's focus on eliminating allocations, this is a relevant detail to consider.

[JoonghyunCho]

🤖 [AI Review]
🟡 Suggestion: The lambda still captures startIndex, count, and collectionView, forcing a per-call closure allocation — so the PR's stated "zero per-call allocation" goal is not fully achieved here. A reverse-iteration for loop with RemoveAt eliminates both the temp list and the closure with no behavior change.

Suggested change

	VisibleItems.RemoveAll(item =>
	{
	if ((item.Index >= startIndex)
	&& (item.Index < startIndex + count))
	{
	unrealizedItems.Add(item);
	collectionView.UnrealizeItem(item);
	return true;
	}
	else if (item.Index >= startIndex + count)
	if (item.Index >= startIndex + count)
	{
	item.Index -= count;
	}
	}
	VisibleItems.RemoveAll(unrealizedItems.Contains);
	unrealizedItems.Clear();
	return false;
	});
	for (int i = VisibleItems.Count - 1; i >= 0; i--)
	{
	RecyclerViewItem item = VisibleItems[i];
	if (item.Index >= startIndex && item.Index < startIndex + count)
	{
	collectionView.UnrealizeItem(item);
	VisibleItems.RemoveAt(i);
	}
	else if (item.Index >= startIndex + count)
	{
	item.Index -= count;
	}
	}

[JoonghyunCho]

🤖 [AI Review]
Addressed in 03a8955 — replaced RemoveAll(lambda) with a reverse for loop using RemoveAt, eliminating both the temp list and the closure allocation on this path.

[JoonghyunCho]

🤖 [AI Review]
Addressed review feedback in commit 03a8955. Summary: replaced the four VisibleItems.RemoveAll(lambda) sites in LinearLayouter/GridLayouter (RequestLayout + NotifyItemRangeRemoved) with a reverse for + RemoveAt loop, eliminating the per-call closure allocation.