TO_DO (Original-Liste, Status nach der Portierung auf Pi4/Pi Zero 2W + mpv-Architektur):

 - [ERLEDIGT] effizientere Möglichkeit zum PNG laden; stb_image.c braucht lange zum kompilieren
   -> stb_image.c ist eine alte Version (1.33) ohne STBI_ONLY_PNG-Unterstuetzung
      (siehe Kommentar in CMakeLists.txt). Kompiliert jetzt mit -O1 statt der
      Standard-Optimierungsstufe - PNGs werden nur einmal beim Programmstart
      geladen, kein Hot-Path, daher kein Laufzeitnachteil. Spart spuerbar
      Build-Zeit ohne das Risiko, die Bibliothek komplett auszutauschen.

 - [ERLEDIGT] ArtNet Receiver Thread schreibt einfach die canvas eigenschaften,
   diese werden eventuell zeitgleich gelesen; eventuell mutex einbauen
   -> Alle betroffenen Canvas-Felder sind jetzt std::atomic<...> (siehe
      canvas.h) statt einfacher Member. Verhindert Data Races zwischen dem
      Art-Net-Empfangs-Thread und der Render-Schleife, ohne dass ein Mutex
      die Render-Schleife blockieren koennte. Kompiliert ohne weitere
      Anpassungen an canvas.cpp (Canvas wird nirgends per Wert kopiert).

 - [ERLEDIGT] google nach Umwicklungsartefake (GL_REPEAT) - Texturwiederholungen am Rand
   -> Ursache gefunden: GLES2 verlangt bei Non-Power-of-Two-Texturen (z.B.
      Fotos mit 1920x1080) zwingend GL_CLAMP_TO_EDGE statt des Default-Werts
      GL_REPEAT, sonst gilt die Textur als "unvollstaendig". Ueberall
      ergaenzt (texture.cpp, content_example_plugin.cpp).

 - [ERLEDIGT] Framerate bei Berechnungen beruecksichtigen? Fehlerbehandlung wenn FPS absinkt?
 - [ERLEDIGT] soll Shutter und/oder Autodrehungen per Frame oder pro Zeit berechnet werden?
   -> Beides jetzt zeitbasiert statt framebasiert: Rotation nutzt die
      TATSAECHLICH gemessene Zeit seit dem letzten Frame (nicht die
      konfigurierte Ziel-FPS), Shutter/Strobe genauso. Damit bleibt die
      Geschwindigkeit korrekt, auch wenn die Render-Schleife durch
      GL-Readback/Pipe-Schreiblast mal langsamer laeuft als die
      konfigurierte RENDER_FPS.

 - [TEILWEISE ERLEDIGT] Windows Beamertool scheint irgendeine Form von Antialiasing
   bei den Texturen zu machen, hier nicht
   -> Gobo-Texturen (PNG/GIF) nutzen jetzt GL_LINEAR statt GL_NEAREST fuer
      weichere Kanten beim Skalieren/Rotieren. Fuer Fotos/Videos im Media
      Player uebernimmt mpv ohnehin sein eigenes (gutes) Scaling.

 - [OFFEN] Latenz verringern; Rendering optimieren, etc.
   -> Durch den Architekturwechsel auf mpv als alleinigen, robusten
      Anzeigepfad (siehe README) gibt es jetzt einen zusaetzlichen
      Umweg: Rendern -> glReadPixels -> FIFO -> mpv-Rawvideo-Decode.
      Das kostet etwas mehr Latenz als das urspruengliche direkte
      SDL2/kmsdrm-Rendering, war aber noetig, weil dieser direkte Pfad auf
      manchen Pi4/Debian-13-Kombinationen unzuverlaessig war (siehe
      Projekthistorie). Stellschrauben bei Bedarf: RENDER_WIDTH/HEIGHT/FPS
      in config.txt reduzieren.

 - [OFFEN] Kommentieren; Quellcode ordentlich formatieren
   -> Alle neuen/veraenderten Dateien (Renderer, MpvDisplay, MediaPlayer,
      Mat4, gl_state, ...) sind ausfuehrlich auf Deutsch kommentiert.
      Unveraenderte Originaldateien (artnet_receiver.cpp, config_loader.cpp,
      console_screen.cpp) behalten die urspruengliche Kommentierung/Formatierung.

 - [NEU, bekannte Einschraenkung] Video-Gobos (Textur-Dateien wie z.B. 194.h264)
   innerhalb der Laser-Simulation werden aktuell NICHT dekodiert (blauer
   Platzhalter) - ein zusaetzlicher Video-Decoder-Prozess pro Textur-Slot
   wuerde mit dem alleinigen mpv-Anzeigepfad kollidieren. Liesse sich bei
   Bedarf sauber ueber denselben FIFO-Mechanismus nachruesten, den der
   Media Player fruehruer testweise fuer Bilder/Videos nutzte (Frame-Decode
   direkt in eine GL-Textur statt externem Prozess).

Anpassung an Original:
   Passt inhaltlich weiterhin, abgesehen von: Animationsregler (unbenutzt,
   da Video-Gobos siehe oben), Einstellmoeglichkeit fuer Zoom (unveraendert
   vom Original uebernommen), und dem neuen, zusaetzlichen Media Player
   (kein Teil des Original-Funktionsumfangs).
