Matze hat schon recht, manchmal moechte man lieber auf die Pixel direkt zugreifen koennen[1]. Mit esskars Loesung wuerde man bei einem kleinen Fenster von 300x300 Pixeln einen Canvas mit 90_000(!) Objekten verwalten muessen, was wohl die meisten Rechner ueberfordert. Tk scheint aber nur diesen objektorientierten Ansatz zu bieten und keinen direkten Zugriff auf die Pixel eines Fensters.

Eine Moeglichkeit mit Tk waere vielleicht, auf einer internen Pixmap zu arbeiten und diese immer wieder in ein Tk::Image-Objekt zu kopieren. Aus Effizienzgruenden koennte man einen Canvas in mehrere Image-Objekte aufteilen, damit nicht bei jeder Aenderung ein grosses Objekt kopiert werden muss.

Alternativ koennte man auch z.B. mit der SDL-Grafiklibrary arbeiten. Ich habe zwar keine Erfahrung damit, aber Spiele wie Frozen Bubble zeigen, dass man damit grafisch ansprechend mit Perl programmieren kann. (Mit Frozen Bubble kann man schoen Leute widerlegen, die der Meinung sind, Perl eigne sich nicht fuer grafiklastige Spiele.)

[1] Zu Zeiten eines C64 und auch noch beim Atari ST/TT konnte man fuer schnelle Pixelgrafiken direkt auf den Bildspeicher zugreifen und dort hineinschreiben. Ach, was habe ich da alles an einfachen Simulationen (Game of Life, Kristallwachstum, Stroemungsverhalten) auf den 640x400 monochrom programmiert ...
Bei Singletasking-Rechnern ist das alles kein Problem, aber wenn man mit Multitasking-Systemen und verschiedenen Fenstern arbeitet, muss man sich schon um Redraws kuemmern, was ein direktes Arbeiten im Bildschirmspeicher praktisch unmoeglich wird - man muss Buffering oder Double-Buffering nehmen und mit memcpy (wer erinnert sich noch an bitblt-Operationen?) auf den Bildschirm kopieren.