← Visualizers
Graphs · Flood fill on a grid LeetCode 733

Flood Fill / visualized

The atom of every grid problem: neighbours are computed, never stored, and the four-direction loop and the in-bounds guard are one unit. It also carries the smallest trap in the syllabus — when the new colour already equals the old one, the recursion has nothing left to change, so nothing ever stops it.

Execution

idle
Press Run to begin.
0 / 0
Speed

Java · running line

current cell on the call stack repainted a different colour
O(m·n) time, O(m·n) worst-case stack  ·  the guard is not an optimisation. Repainting is what makes a cell fail the == old test next time, so when new == old nothing is ever marked. Any cell with a same-colour neighbour then bounces between the two forever — an isolated cell is the one case that still terminates, which is why the bug can pass a careless test.