Öhm *schäm* Was ich ganz vergessen habe. Du musst überhaupt kein UnionRect erzeugen. Das macht ja OS X für dich. So jetzt scxhaue ich mir mal die Werte an. Gibt gleich ein Update.

Neee, das scheint richtig zu sein. Er vergrößert dafür ja die Weiten kräftig.

Hmmmm, wenn du den Befehl auskommentierst, dann zoomt er doch gar nicht mehr? Oder meintest du den bereits auskommentierten Befehl?

Ja, das meinte ich übrigens. Ich schrieb ja schon eingangs, dass -setNeedsDisplayInRect:(NSView) lediglich die Region zum zeichnen markiert. Innerhalb einer Event-Loop sammelt er alle invalidated Rects und schickt dann beizeiten ein Redraw-Event, welches in deinem drawRect mündet. Schau dir nochmal die Doku dazu an. Hier nur mal die Methodenbeschreibung von mir hervorgehoben:

Marks the region of the receiver within invalidRect as needing display, increasing the receiver’s existing invalid region to include it. A later displayIfNeeded... method will then perform drawing only within the invalid region. NSViews marked as needing display are automatically redisplayed on each pass through the application’s event loop. (View objects that need to redisplay before the event loop comes around can of course immediately be sent the appropriate display... method.)

Also, bei mir funktioniert's ...

Ich glaube auch weiterhin, dass da ein Rundungsfehler vorliegt. Das Fehlerbild ist einfach zu eindeutig.

Wegen des auf den Kopf stehen: Du hast doch -isFlipped(DeinView) implementiert? Ansonsten musst du setBound und setFrame nicht überschreiben. Benutze sie einfach. Ich mache es auch so.

Klar, bei mir ist das auch ein NSScrollView. Wenn gezoomt werden kann ...

Hmmmm, hast du dir mal alle Ints aus den beteiligten Modulen heraussuchen lassen?

Für das Setzen ein einfaches Beispiel, mal schnell aus dem Keller geholt:

Das ist jetzt Zoom-Faktor 2. Wichtig ist, dass du die Bounds nach dem Frame setzt, da eine Veränderung des Frames die Bounds mitverändert. Eine setZoom-Methode sieht daher wie folgt aus:



Die Umrechnungsbasis für Maus etc. machst du bitte nicht über Origins! Dafür gibt es -convertPoint:fromView:(NSView) et al.
Ist aber wie gesagt alter Code, so dass ich keine Gewähr übernehme.

Öhm, also vorsichtig ausgedrückt: Auf meinem System läuft's ...

Nein, zumal die offenbar selbst -setBounds:(NSView) aufrufen.

Aber bei einer so häufig benutzten Methode, würde es mich doch sehr wundern, wenn sie nicht funktionieren würde. Immerhin dürfte es 98721983791283798 Apps geben, die in einem Scroll-View zoomen. Und bisher habe ich nichts von einem Problem gehört ...

Aber, das sage ich jetzt einfach mal so, du hast ja schon einige Dinge hingefriemelt (Origin, Union-Rect etwa), du bist auch offenbar noch neu und kanntest viele Funktionen nicht. Hältst du es da nicht mindestens für wahrscheinlich, dass der Fehler bei dir liegt? Was macht dich so sicher, dass es anders ist?

Hmm, also die Vergrößerung ist doch klar: Welche Eigenschaften hat denn dein View? Schatten? Umrahmung? Das rechnet Cocoa automatisch mit ein.

Du kannst mir ja mal das Projekt schicken. Vielleicht finde ich die Zeit, hereinzuschauen.

Ich weiss ja nicht, ob sich das Problem mittlerweile erledigt hat, aber hier mein Senf:

Das sieht in der Tat nach irgend etwas mit Rundung oder Antialiasing aus. Ob das ein wirklicher Rundingsfehler ist, weiß ich nicht. Wie malst Du denn Deinen Hintergrund? Füllst Du das in [drawRect: ] übergebene Rechteck? Setzt Du das Clipping explizit? Das sind die einzigen Möglichkeiten, die ich sehe, dass sowas passieren kann. Denn egal wie Deine rects aussehen: Der scrollView/clipView und Dein documentView bekommen ja das gleiche Clipping, also sollte es unmöglich sein, dass der ClipView irgendwelche Pixel malten kann, die in Deinem [drawRect: ] nicht erreicht werden. Wenn das so wäre, würde ich an diesen Stellen das Rechteck etwas ausweiten.

Etwas anderes: Deine floor()- und ceil()-Geschichte tut wahrscheinlich nicht immer das, was Du bezweckst. Ein Beispiel: Ein Rect mit dem Ursprung (3.9,3.9) und Größe (3.9,3.9) hat logischerweise als rechte untere Ecke (7.8,7.8 ). Nach Deiner Rundung wird's zu Origin (3.0,3.0) und Size (4.0,4.0). Also liegt die untere Ecke nun bei (7.0,7.0) - der Bereich zwischen 7.0 und 7.8 fehlt! Schau mal nach NSIntegralRect() - das sollte es tun.

Das aber nur nebenbei - ich habe ein ähnliches Programm hier, mit View in ScrollView und [setNeedsDisplayInRect: ], das macht keine Blitzer, auch ganz ohne Rundung.

Nun, durch das Runden von Zahlen verlierst Du ja Information. Im Falle von Grafikkoordinaten verschieben sich dadurch Punkte. Wie sich das auswirken kann, hat mattik in seinem Beispiel eigentlich sehr schön beschrieben. In dem Beispiel ist das Rechteck durch Runden zwar Größer geworden, aber es hat sich auch so verschoben, dass es den ursprünglichen Bereich nicht mehr vollständig überdeckt.

Michael

Na, sowohl mattik als auch ich haben dir doch Beispiele genannt.

Das Problem ist, dass du möglicherweise weniger "draufrundest" als du durch die Umwandlung in Ints verlierst. Richtig wäre es, wenn du die Punktkoordinaten runden würdest anstelle Origin/Size. Also, nochmal mit den Zahlen von mattik (meine sind auf der ersten Siete, kannst ja noch einmal reinscheuen.

Origin = 3,9|3,9
Size = 3,9|3,9

Nehmen wir nur die X-Richtung:
Das ist der Anfangspunkt3,9 und der Endpunkt 7,8. Wenn du Origin und weite rundest, kommst du auf 3 und 4, was im Ergebenis die Punkt 3 und 7 bringt. Die Strecke 7,0 bis 7,8 wird nicht gezeichnet. Abhilfe schafft hier das Runden der jeweiligen Punkt: 3 und 8 ergeben sich dann, die du als 3 und Weite 5 speicherst.

Aber das Ganze solltest du ohnehin weglassen. Koordinaten _sind_ floats. Die frühere Annahme, es seien Flächen, ist unter Cocoa fehlerhat. Das ist auch nicht nur eine Zahlenspielerei, sondern hat Konsequenzen. Hier habe ich das etwa an einem Beispiel beschrieben:
Bild zeichnen. Mal scharf, mal unscharf.

Also, langer Rede kurzer Sinn: Runde nicht!

Ob du das Superview zeichnest schaue ich bei Gelegenheit mal nach. Es kann durchaus sein, dass das drawRect einen _größeren_ Bereich als das eigentlich View fordert. Dann muss das Superview freilich den Hintergrund zeichnen.