Warum schmiert eine 680x1560-Pixel-Zeichnung in VB.NET 2003 beim Scrollen in den unteren 60 Pixeln?

**Das „Schmieren“ unten ist sehr wahrscheinlich kein Größenlimit deiner 680×1560-Zeichnung, sondern ein Repaint-/Scroll-Problem: Beim Scrollen verschiebt Windows nur die vorhandenen Pixel und zeichnet oft nur den neu freigelegten Streifen nach – wenn dein Code nicht den kompletten sichtbaren Bereich sauber neu zeichnet, bleiben unten Artefakte stehen.** ([stackoverflow.com](https://stackoverflow.com/questions/21331054/glitch-on-winforms-panel-when-overriding-onpaint)) ## Was dabei konkret passiert In WinForms bzw. schon im alten VB.NET 2003 wird beim Scrollen aus Performance-Gründen nicht immer alles neu gerendert. Der sichtbare Inhalt wird erst einmal „verschoben“, und nur der neu sichtbar gewordene Bereich wird invalidiert. Genau dadurch entstehen typische Schmier- oder Nachzieheffekte, besonders am unteren Rand. ([stackoverflow.com](https://stackoverflow.com/questions/21331054/glitch-on-winforms-panel-when-overriding-onpaint)) Die „unteren 60 px“ sind deshalb meist kein magischer Wert der Bildhöhe, sondern der Bereich, der beim Scrollen gerade neu aufgedeckt wird oder durch Scrollbar-/Clientbereich-Rechnung falsch behandelt wird. Wenn du z. B. mit `CreateGraphics` direkt zeichnest, außerhalb des `Paint`-Ereignisses malst oder nur Teilbereiche aktualisierst, ist so ein Fehler fast vorprogrammiert. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/custom-painting-drawing)) ## Die häufigsten Ursachen in VB.NET 2003 1. **Zeichnen mit `CreateGraphics` statt im `Paint`-Ereignis** Dann ist die Zeichnung nicht persistent. Beim Scrollen oder Überdecken fehlen Teile. 2. **Falscher Scroll-Ansatz mit PictureBox** Eine `PictureBox` hat keine echte eingebaute Bild-Scroll-Logik. Wenn du den Inhalt „manuell“ verschiebst, ohne sauber neu zu zeichnen, entstehen genau solche Effekte. ([stackoverflow.com](https://stackoverflow.com/questions/4676745/how-can-i-show-scrollbars-on-a-picturebox-control)) 3. **Nur Teilbereiche werden neu gezeichnet** Wenn dein Code annimmt, dass nur das Objekt selbst neu gemalt werden muss, aber nicht der komplette sichtbare Ausschnitt, bleibt unten alter Pixelmüll stehen. 4. **Clienthöhe falsch berechnet** Gerade in alten WinForms-Versionen führen Scrollbar, Border, StatusBar oder Docking leicht dazu, dass ein Restbereich unten nicht korrekt berücksichtigt wird. 60 px passen verdächtig gut zu „irgendein UI-Bereich wird mitgerechnet oder vergessen“. ## Was praktisch die richtige Lösung ist Der robuste Weg ist: - **nicht direkt auf das Formular oder die PictureBox „dauerhaft“ zeichnen** - **alles im `Paint`-Ereignis eines eigenen Controls oder Panels zeichnen** - beim Scrollen **`Invalidate()`** aufrufen, notfalls für den ganzen sichtbaren Bereich - die Zeichenposition immer aus dem aktuellen Scroll-Offset berechnen Der entscheidende Unterschied ist: **Nicht Pixel verschieben, sondern den sichtbaren Ausschnitt jedes Mal neu zeichnen.** Das ist in alten WinForms deutlich stabiler als „malen und hoffen, dass es stehen bleibt“. ## Typischer Denkfehler Viele alte VB.NET-Programme behandeln eine Zeichnung wie eine feste Leinwand. WinForms behandelt sie aber eher wie eine Ansicht, die jederzeit neu aufgebaut werden muss. Wenn du das nicht beachtest, schmiert es beim Scrollen, beim Minimieren und oft auch beim Überdecken durch andere Fenster. ([learn.microsoft.com](https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/custom-painting-drawing)) ## Konkrete Empfehlung Wenn du bei VB.NET 2003 bleiben musst, ist die beste Lösung meist: - Zeichnung in ein **Bitmap** rendern - dieses Bitmap im `Paint`-Ereignis anzeigen - gescrollt wird nur die **Ansicht auf das Bitmap**, nicht die Zeichnung selbst Oder noch besser: - ein eigenes scrollbares Control verwenden - im `OnPaint` immer den sichtbaren Bereich anhand des Scroll-Offsets neu zeichnen **Kurz: Das Problem sitzt fast sicher im Repaint beim Scrollen, nicht in den 1560 px Höhe. Die unteren 60 px schmieren, weil dieser Bereich nicht korrekt neu gezeichnet wird.** Wenn du willst, kann ich den typischen Fehler in altem VB.NET-2003-Code auch direkt an einem kleinen Beispiel zeigen.