Warum führen bei DrawLine int- und float-Parameter zu unterschiedlichen Ergebnissen

Morgen @all!

Sitze hier jetzt schon mehrere Stunden (gestern auch schon) und zweifele schon fast an meinem Verstand.

Es geht um einen Formulardesigner und ein Problem beim Verschieben der Objekte (siehe Anhang).

Beim Verschieben des Fragenelementes nach oben sind immer (nur) die horizontalen Linien bei den Zahlenblöcken verschwunden.
Die Bounds-Bereiche der beiden Elemente die ich vor und nach dem Verschieben Invalidieren lassen sind 100%ig richtig.

Jetzt hab ich den Fehler beheben können und bin etwas baff.
Und zwar liegt es irgendwie am überladenen Konstruktor von DrawLine ob ich entweder die int- oder die float-Werte übergebe.

Meine Frage:
Sind beide Codeausschnitte äquivalent, bzw. müsste die GDI nicht in beiden Fällen dasselbe Ergebnis ausgeben?
Rundet die Funktion intern anders?

Vor allem ist die Ausgabe auch wirklich Pixelgenau gleich.
Nur beim verschieben bleiben mit unterem Code die Horiz. Striche der Zahlenblöcke bestehen

       float offset = _penBlock.Width / 2;
       .
       .
        g.DrawLine(_penBlock,
          ZahlenblockX - offset,
          ZahlenblockY - offset,
          ZahlenblockX + (3 * (_blockBreite + _penBlock.Width)) - offset,
          ZahlenblockY - offset);

       float offset = _penBlock.Width / 2;
       .
       .        
       g.DrawLine(_penBlock,
          (int)(ZahlenblockX - offset),
          (int)(ZahlenblockY - offset),
          (int)(ZahlenblockX + (3 * (_blockBreite + _penBlock.Width)) - offset),
          (int)(ZahlenblockY - offset));

Ps. Hab noch das hier gefunden:
http://www.tech-archive.net/Archive/Development/microsoft.public.win32.programmer.gdi/2004-08/0350.html

Bei mir ähnlich, mit Antialising gibts auch keine Probleme

Meine Frage:
Sind beide Codeausschnitte äquivalent, bzw. müsste die GDI nicht in beiden Fällen dasselbe Ergebnis ausgeben?
Rundet die Funktion intern anders?

der cast gegen int hackt den nachkommaanteil einfach ab. so wird aus einer 1.99999 eine 1

wenn du den float-wert übergibst, rundet er zum nächstgelegenen pixel und das wäre im oberen beispiel die 2

Hi JAck30lena,

der cast gegen int hackt den nachkommaanteil einfach ab. so wird aus einer 1.99999 eine 1

wenn du den float-wert übergibst, rundet er zum nächstgelegenen pixel und das wäre im oberen beispiel die 2

Das mit dem Nachkommaanteil abhacken stimmt schon.

Nur ein Pixel Versatz kann diesen Effekt nicht aufrufen.

In Abb.1 hab ich den Bounds-Bereich, der per Invalidate(bounds) aktualisiert wird mal blau mitzeichnen lassen. Ich hab extra unten am Frageelement mehr Platz gelassen.
Trotzdem kann man mit dem unteren Teil die horizontalen Striche vom Zahlenblock 'wegwischen', wenn man ihn senkrecht nach oben zieht und der Float-Konstruktor benutzt wird.

Und ich hab in Abb.2 mal einen Test gemacht: Hier rundet die GDI auf X und Y Achse unterschiedlich ?!??
Da müsste doch eigentlich das äquivalente Ergebnis gezeichnet werden oder sehe ich das falsch?

Komische GDI

Ps. Sorry wg. wenig aussagekräftigen Titel vorhin

setze den zu invalidierenden bereich immer genau einen pixel breiter und höher als er laut berechnung eigendlich benötigt wird.

setze den zu invalidierenden bereich immer genau einen pixel breiter und höher als er laut berechnung eigendlich benötigt wird.

Ist er doch schon (siehe blauen Bereich).
Das ist die List<Rectangle> die Invalidiert wird.

Genau am unteren Bereich ziehts mir die Striche weg, auch wenn ich noch 10Pixel dranhänge...

(muss doch nicht genau ein Pixel mehr sein, oder ?)

Hallo zusammen,

nur zur weiteren Info (alle Beiträge, aber speziell verlinkter):
System.Drawing Float

Grüße
Norman-Timo

Hallo norman_timo,
Danke erstmal für deinen Link, ich hab die Threads und den Artikel 'BorderBug' vom Codeprojekt mal durchgelesen, wobei es mir hier weniger um Image-Resizing geht.
(http://www.codeproject.com/KB/graphics/BorderBug.aspx)

Ich halte mich mal einfach an ein Zitat von dir und betrachste das einfach als meine Lösung:

GDI+ wird bei Floating-Werten im Zusammenhang mit Pixelpositionen anfangen zu interpolieren (das ist der schon angesprochene Durchscheineffekt).

Das kann ich jetzt nicht direkt mit einer Quelle belegen, habe es aber selbst einmal evaluiert. Falls Du gestochen scharfe Linien/Bilder zeichnen willst, wäre es am sinnvolsten die Positionen selbst vorab zu runden.

Anders kann ich mir das Verhalten meines Designers echt nicht erklären... 🤔