Die Schnittpunktberechnung wird extrem billig, wenn man das ganze auf einem bereits gezeichneten Polygon macht (bei dem Hintergrund- und Polygonfarbe genau unterschieden werden können): Bei einem Farbwechsel befindet man sich im nächsten Pixel auf der anderen Seite des Polygons als vorher. Man muss nur den Sonderfall horizontaler Linien bedenken, d.h. so lange nach einem Wechsel die neue Farbe in weiteren Pixeln auch ist, ist man noch nicht angekommen.
Einziges Problem ist dabei, dass es Grenzfälle gibt. Beispiel:
Code:
XXXXXX
X X
XX <- unfein
X X
XXXXXX
Der "Scanline"-Ansatz ist insgesamt aber auch der gängige. Wie man genau die Schnittpunkte ermittelt ist dann zweitrangig, und man muss eben schauen was für den jeweiligen Fall praktikabel ist. (In der Graphics32 gibt es für TPolygon32 z.B. ein Event OnFillScanline() o.ä., mit dem man einen Custom-Filler anflanschen kann. Die Klasse nutzt intern das gleiche Verfahren.)
Die o.g. Grenzfälle kann man "schmutzig" eliminieren, wenn du dein Polygon performant komplett ausfüllen kannst: Pixel hat Füllfarbe -> du bist drin und kannst deine Schraffur drauf los lassen. Da braucht es dann aber spätestens eine Kopie in einem separaten Bitmap; eine für gefülltes Arbeitspolygon, eine im eigentlichen Bild. (Was es auch beim anderen Ansatz bräuchte, wenn der Hintergrund bereits vorbemalt ist.)
Das Verfahren sollte aber erst dann wirklich merkbar schneller werden, wenn die Polygone sehr viele Segmente haben, die man sonst mathematisch schneiden müsste. Das geht bei Gerade-Gerade ja wirklich sehr flott.
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)