Bug: IntersectRect liefert falsche Resultate

[gammatester]

Zitat von Amateurprofi:

Nein, gerade das ist ja der Fehler in den Funktionen.

Beispiel: Nimm ein Rechteck, teile es senkrecht in der Mitte, nenne den linken Teil B, den rechten A. Dann haben A und B eine Seite gemeinsam und damit einen nicht-leeren Durchschnitt. Es ist B.Right=A.Left, also gerade nicht B.Right < A.Left und damit der gesamte Ausdruck mit and falsch und Deine Funktion liefert ein falsches Ergebnis.

[stahli]

Das gelbe Rect1 ist Left=2 und Right=5.
Der Bereich ist dann real 2..4.

Das blaue Rect2 ist dann Left=5 und Right=8.
Der Bereich ist dann real 5..7.

Die beiden Rects grenzen nur aneinander, aber es gibt keine Überschneidung.

Dass die Rects Left und Top den realen Wert widerspiegeln und Right und Bottom 1 Pixel weiter außerhalb liegen hat mich auch schon einige graue Haare gekostet (trage jetzt Glatze )

[Uwe Raabe]

Zitat von gammatester:

Beispiel: Nimm ein Rechteck, teile es senkrecht in der Mitte, nenne den linken Teil B, den rechten A. Dann haben A und B eine Seite gemeinsam und damit einen nicht-leeren Durchschnitt. Es ist B.Right=A.Left, also gerade nicht B.Right < A.Left und damit der gesamte Ausdruck mit and falsch und Deine Funktion liefert ein falsches Ergebnis.

Die Defintion von TRect besagt aber gerade, daß die so geteilten Rechtecke eben nicht eine Seite gemeinsam haben. Die Trennlinie beschreibt zwar die rechte Kante des linken Rechtecks, gehört aber per Definition nicht dazu.

Anders ausgedrückt würde eine Schleife über die X-Werte eines Rechtecks so lauten:
for I := A.Left to A.Right - 1 do

Wie schon erwähnt, ist dies in späteren Delphi-Versionen gefixt.

[Amateurprofi]

Zitat von gammatester:

Zitat von Amateurprofi:

Nein, gerade das ist ja der Fehler in den Funktionen.

Beispiel: Nimm ein Rechteck, teile es senkrecht in der Mitte, nenne den linken Teil B, den rechten A. Dann haben A und B eine Seite gemeinsam und damit einen nicht-leeren Durchschnitt. Es ist B.Right=A.Left, also gerade nicht B.Right < A.Left und damit der gesamte Ausdruck mit and falsch und Deine Funktion liefert ein falsches Ergebnis.

Ich sprach (schrieb) nicht über EIN Rechteck, das wie auch immer durch eine Linie geteilt ist sondern über ZWEI aneinander grenzende Rechtecke.
Bleiben wir trotzdem bei Deinem Beispiel.
Wir haben also ein Rechteck.
Der obere linke Eckpunkt soll bei 5,5 liegen und es soll 60 Pixel breit und 30 Pixel hoch sein.
Nun trennen wir es in der Mitte durch eine senkrechte Linie und nennen den linken Teil B und den rechten Teil A.
Da wir die beiden Rechtecke ja nicht nur denken sondern auch zeichnen wollen, brauchen wir die Koordinaten von A und B.
Wenn wir die haben, zeichnen wir beide Rechtecke mit Canvas.Rectangle, wobei beide Rechtecke einen 1 Pixel breiten Rahmen haben sollen und die Rechtecke und Rahmen sichtbar unterschiedliche Farben haben sollen, damit wir genau sehen wo welches Rechteck beginnt und wo welches endet.
Liefere du bitte die Koordinaten der beiden TRects A und B.

[stahli]

Wenn man in der Mitte eine Linie zieht und diese beide Rects begrenzt überschneiden sich beide tatsächlich um ein Pixel.
Man muss also das rechte Rect noch um ein Pixel nach rechts verschieben und erhält die gegebene Situation (und in der Mitte eine 2 Pixel breite Linie).

Ich sehe gerade, in XE3 ist die Funktion auch noch falsch und ich hatte auch eine eigene geschrieben.

[himitsu]

Hatte ich hier nicht schonmal geantwortet?

Also, das Problem ist, dass diese TRect-Funktionen eigentlich richtig funktionieren, aber die Zeichenfunktionen den Endpunkt nicht einbeziehen (was ich eher als Fehler erachte, aber das ist halt schon seit vielen Jahrzehnten so)

TCanvas.Rectangle, TCanvas.Line, TCanvas.PolyLine usw. sind im Entpunkt der Operation um ein Pixel verschoben, wie ihr schon bemerkt habt.
Aber dennoch arbeitet IntersectRect eigentlich richtig, nur halt nicht so, wie es die Zeichenfunktiopnen vorgeben, sondern nur auf den eigentlichen Wertebereich bezogen.

[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.

[Amateurprofi]

Zitat von himitsu:

Hatte ich hier nicht schonmal geantwortet?

Also, das Problem ist, dass diese TRect-Funktionen eigentlich richtig funktionieren, aber die Zeichenfunktionen den Endpunkt nicht einbeziehen (was ich eher als Fehler erachte, aber das ist halt schon seit vielen Jahrzehnten so)

TCanvas.Rectangle, TCanvas.Line, TCanvas.PolyLine usw. sind im Entpunkt der Operation um ein Pixel verschoben, wie ihr schon bemerkt habt.
Aber dennoch arbeitet IntersectRect eigentlich richtig, nur halt nicht so, wie es die Zeichenfunktiopnen vorgeben, sondern nur auf den eigentlichen Wertebereich bezogen.

Nein, es ist genau umgekehrt.
Die Zeichenfunktionen arbeiten korrekt und IntersectRect und IntersectsWith arbeiten falsch.
Den Funktionen werden als Parameter TRect's übergeben und TRect ist nun einmal so definiert, dass Right und Bottom außerhalb der Fläche liegen.
Merke:
Eine Funktion arbeitet dann korrekt wenn sie das macht was der zugehörigen Dokumentation steht.
Ob dass dann auch den persönlichen Erwartungen entspricht, ist eine andere Sache.
Ein (zugegebenermaßen weit hergeholtes) Beispiel:

Delphi-Quellcode:

// Beschreibung: Mod gibt die Summe von A und B zurück
FUNCTION Mod(A,B:Integer):Integer;
begin
   Result:=A+B:
end;

Wenn nun Mod(15,3) = 18 ergibt, dann arbeitet sie korrekt, denn sie macht das, was in der Dokumentation steht.
Wenn der Anwender, der wahrscheinlich das Ergebnis 0 erwartet meint, sie arbeitet falsch, dann irrt der.
Und in der Beschreibung von zum Beispiel TRect.IntersectsWith steht
"returns true if any part of the rect covers R"
Im Fall dass die beiden Rechtecke aneinander Grenzen, machen spwohl IntersectRect und TRect.IntersectsWith nicht das, was in der Dokumentation steht, also arbeiten sie falsch und nicht "eigentlich richtig".

Allerdings ist die weitere Diskussion überflüssig, denn, wie Uwe schrieb, wurden die Funktionen in späteren Delphi Versionen korrigiert.