Probleme mit drawRect: - bin mir aber nicht sicher

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Probleme mit drawRect: - bin mir aber nicht sicher

    Hallo ihr Helfenden...

    in meinem Projekt verwende ich eine ganze Latte an Custom-Controls resp. div. Sub-Klassen von NSView/NSButton (NSButtonCell). In fast allen wird in drawRect: irgendwas gezeichnet und befuellt etc. Nur frage ich mich langsam, ob das wirklich der richtige Platz fuer diese Aktionen ist.

    Warum? Stutzig wurde ich beim Bewegen des App-Fensters ueber den Desktop. Das schaut alles andere als smooth aus. Da ruckelt und flackert es wie wild. Mir kam auch gleich eine Idee, woher das kommen koennte. Also hab ich in all meine drawRect: Methoden eine Log-Ausgabe eingepflanzt um zu sehen, was da abgeht. Und ich staunte nicht schlecht. Bewege ich das Fenster auch nur einen Quadratpixel von seiner Stelle, dann sieht sich meine App auf Deibel-Komm-Raus genoetigt alles neu zu zeichnen, also eine Message an meine drawRect: zu senden. Und das, obwohl sich dort nirgends was aendert (ausser der Position auf dem Screen).

    Kann mir hier jemand bitte einen Tip geben, was ich flasch mache?

    Danke
  • Zeichnen in drawRect: ist absolut richtig. Nur da. Und nur zeichnen, nichts anderes.

    Da darf eigentlich auch nichts flackern - das Zeichensystem ist schlau genug, die Views erst offscreen zu rendern und dann flackerfrei zusammenzukopieren.

    Triggerst Du drawRect: irgendwo von Hand? Änderst Du irgendwo händisch den Focus oder Graphics Context oder derlei Zeug? Das sind m.E. eher die üblichen Verdächtigen.

    Edit: Da war der Wolf mal wieder schneller, wir scheinen aber einen ähnlichen Verdacht zu haben...
    Multigrad - 360°-Produktfotografie für den Mac
  • Hast Du nen Timer laufen?
    Ich hab nämlich grad ein ähnliches Problem, ich hab nen Timer der die drawRect triggert, blöderweise wird gleichzeitig eine andere drawRect (andere Klasse) aufgerufen die eigentlich mit dem Timer nix zu tun hat.
    Sehr strange!
  • Oder mal anders gefragt:
    Wann sollte ich eigentlich:

    Quellcode

    1. NSGraphicsContext* theContext = [NSGraphicsContext currentContext];


    und

    Quellcode

    1. [theContext saveGraphicsState];
    2. [theContext restoreGraphicsState];



    aufrufen? Das mache ich naemlich nirgends. Kann dies das Problem sein?

    phranck
  • wolf_10de schrieb:

    Hast Du nen Timer laufen?
    Ich hab nämlich grad ein ähnliches Problem, ich hab nen Timer der die drawRect triggert, blöderweise wird gleichzeitig eine andere drawRect (andere Klasse) aufgerufen die eigentlich mit dem Timer nix zu tun hat.
    Sehr strange!
    Nope. Keinen Timer (-:
  • Kann es nicht einfach sein, dass Du fürchterlich rechenintensive Dinge in drawRect tust? Ich meine die Leute kommen heutzutage da gerne auf so Ideen wie mal eben ein 8 MegaPixel Image zu skalieren und maskieren oder irgendwelche Gesichtserkennungen laufen zu lassen ;)

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    Kann es nicht einfach sein, dass Du fürchterlich rechenintensive Dinge in drawRect tust? Ich meine die Leute kommen heutzutage da gerne auf so Ideen wie mal eben ein 8 MegaPixel Image zu skalieren und maskieren oder irgendwelche Gesichtserkennungen laufen zu lassen ;)

    Gruß

    Claus
    Hier ein setFill, da ein Stroke und dort Mal ein Shadow oder Gradient. Sonst nix. Selbst, wenn ich einen Grossteil der Controls, die selbst zeichnen, ausschalte, bleibt das Flackern bestehen. Es nimmt zwar ab, je mehr Controls ich ausknipse, aber das Problem besteht weiterhin.

    Normaler Weise bekommt der Inhalt eines Fensters ja durch reines Verschieben des Selben ja nicht so viel mit. Warum sollte er auch? Bei einem Resize ist das was anderes. Aber verschieben...?

    phranck
  • phranck schrieb:

    Jein. Nur an Stellen, bei denen ausdruecklich eine Aktion erforderlich ist, und auch erst NACH der Aktion. Aber beim Fensterverschieben passiert ja auf meiner Seite mal garnix

    Sicher? Ich bleibe mal hartnäckig: Klar, dass man setNeedsDisplay ab und zu braucht. Aber hast Du vielleicht eine Methode des NSWindowDelegate-Protokolls implementiert, so etwas wie windowWillMove ... ?

    Matthias
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • phranck schrieb:

    Oder mal anders gefragt:
    Wann sollte ich eigentlich:

    Quellcode

    1. NSGraphicsContext* theContext = [NSGraphicsContext currentContext];


    und

    Quellcode

    1. [theContext saveGraphicsState];
    2. [theContext restoreGraphicsState];



    aufrufen? Das mache ich naemlich nirgends. Kann dies das Problem sein?

    Wenn Du etwas am Context änderst (Clipping setzen usw.), solltest Du davor den State speichern und danach wieder hervorkramen. Context holen -> saveGraphicsState -> eigenes Zeichnen -> restoreGraphicsState kann eigentlich nie schaden (schlimmstenfalls ist es unnütz).
    Multigrad - 360°-Produktfotografie für den Mac
  • MyMattes schrieb:

    Siher? Ich bleibe mal hartnäckig: Klar, dass man setNeedsDisplay ab und zu braucht. Aber hast Du vielleicht eine Methode des NSWindowDelegate-Protokolls implementiert, so etwas wie windowWillMove ... ?
    Bingo! Das war DER Tip. Ich nutze eine Component INAppStoreWindow, und die war der Uebeltaeter. Argh....
    Sorry, dass ich euch die Zeit gestohlen habe (-;

    Und, danke fuer die Denkanstoesse. Jetzt muss ich erstmal einen Bug filen.

    phranck