Bug: IntersectRect liefert falsche Resultate

[Medium]

Es ist halt wirklich nur eine Definitionsfrage, und beide vorgehensweisen sind gleichermaßen richtig. Man muss sich nur durchgängig auf eins von beidem einigen, um innerhalb seiner "Welt" konsistent zu bleiben. Dieser Interpretationsspielraum ergibt sich allerdings auch nur, so lange man Pixel als kleinste Einheit hat. Ein Pixel hat nämlich, im Gegensatz zu einem Punkt, eine Fläche! Das alleine macht einen gewaltigen Unterschied, da zwei Geraden, die sich so nah liegen wie es nur eben in ihrem System geht, bei Pixeln 2 Einheiten breite belegen, bei reellen Koordinaten aber unendlich dünn sind.
Deshalb muss man im Falle von Pixeln ganz klar definieren, ob meine Beschreibungen die Endpunkte beinhalten oder um eins darüber hinaus gehen. Das eine beschreibt sozusagen die Innenkante, das andere die Aussenkante - weil die Kante hat immer auch eine Breite von mindestens 1, die ich nicht weg bekomme.
Das ist übrigens sicher auch viel Ursache für anfängliche Schwierigkeiten, wenn man auf ein Mal auf FMX umsteigt. Dort werden nämlich reelle Koordinaten benutzt, wo die eigentlichen Kantenmitten (bei Breite 1) auf den n,5-Koordinaten liegen, während man beim VCL Canvas es immer nur mit ganzen Zahlen zu tun hatte. (Demnach wäre es übrigens gerade für FMX richtig, wenn zwei aneinander grenzene Rechtecke eine nicht leere Region einer Strecke gemeinsam haben, hier gibt's nicht mehr groß was zu interpretieren.)

[Sir Rufo]

Wenn Right und Bottom mitgezeichnet würden, wie würde man denn dann ein NULL-Rechteck repräsentieren?

Ein Rechteck mit der Breite und Höhe von 1 ist ein Punkt. Ein Rechteck mit der Breite und Höhe von 0 ist Nichts (=NULL).

Mit der himitsu Definition würde man so ein NULL-Rechteck nicht definieren können. Mit der aktuellen Definition geht das problemlos. Das ist der Grund für diese Definition.