MagiC
Allgemeines zum Shutdown
Der Task-Manager in MagiC
MagiC verfolgt die Philosophie, daß Geschwindigkeit nicht mit brutalen Mitteln wie Grafikprozessoren usw. erreicht werden soll, sondern mit ein wenig Nachdenken. Dazu gehört vor allem, immer nur soviel zu tun, wie nötig ist. Während TOS beim Wechsel des aktuellen Fensters, beim Schließen oder beim Verschieben mit Vorliebe das gesamte Fenster oder gar noch völlig unschuldige, unbeteiligte andere Fenster neu zeichnet, wird dies unter MagiC wirkungsvoll vermieden. Obwohl diese unschöne Eigenschaft des TOS nirgendwo dokumentiert ist, existieren leider Programme und Bibliotheken (etwa die aus dem Buch 'Vom Anfänger zum GEM-Profi'), welche die Eigenschaft nutzen, daß TOS beim Vergrößern eines Fensters dieses immer neu zeichnet.
Dazu ein Beispiel: Nehmen wir an, in ein Fenster passen fünf Spalten nebeneinander, die auch angezeigt werden. Wenn der Benutzer nun das Fenster so weit verkleinert, daß nur noch vier Spalten hineinpassen, sortiert das Programm seine Daten um und veranlaßt anschließend selbständig ein Neuzeichnen des Fensters (TOS zeichnet bei Verkleinerung das Fenster nicht von sich aus neu). Vergrößert der Benutzer dagegen das Fenster auf eine Breite von 7 Spalten, sortiert das Anwenderprogramm die Daten ebenfalls um, veranlaßt jedoch hier kein Neuzeichnen des Fensters. Aufgrund des eher als Fehlverhalten des TOS zu bezeichnenden Verhaltens, das Fenster für diesen Fall immer ganz neu zu zeichnen, findet dann die Ausgabe statt.
MagiC zeichnet nun immer nur den minimal nötigen Teil des Fensters neu; das wären im Fall des Aufziehens eines Fensters höchstens rechts und unten zwei Rechtecke. Für die Programme, die den oben beschriebenen Fehler des TOS ausnutzen, gibt sich so eine Diskrepanz zwischen logischem und physikalischem Bildschirminhalt.
Viel einfacher wäre es gewesen, einfach auf die Fallunterscheidung 'Fenster größer oder kleiner als vorher' zu verzichten und immer im Fall des Umsortierens einen Redraw zu veranlassen. Da das Betriebssystem auch im TOS die Redraws zusammenfaßt, hat ein eventuell überflüssiger Redraw niemals irgendwelche Auswirkungen.
Den gleichen Effekt wie beschrieben hat man übrigens auch beim Vergrößern des Fensters, wenn bereits die unterste Zeile bzw. die rechteste Zeile dargestellt wird.
Auch hier ein Beispiel: Ein Text habe 100 Zeilen, das Fenster habe eine Höhe von 20 Zeilen. Da der Scrollbalken ganz unten ist, werden also die Zeilen 80 bis 100 im Fenster dargestellt. Wird nun das Fenster nach unten vergrößert, so daß etwa 30 Zeilen Platz finden, könnte man eigentlich nur einen weißen Bereich aufziehen, da unterhalb von Zeile 100 ja keine Daten mehr sind. Um dies zu verhindern scrollen die meisten Programme in dieser Situation ihre Daten, in unserem Beispiel um 10 Zeilen nach oben. Folglich zeigt das Programm jetzt die Zeilen 70 bis 100 an; da es aber auf einem TOS- Fehler aufbaut, wird kein Neuzeichnen veranlaßt, was unter MagiC natürlich prompt zur Konfusion führt.
Auch hier wäre ein generelles Neuzeichnen des Fensters beim Umsortieren auch unter TOS nicht nur sauber, sondern auch ohne Nebenwirkung, da TOS auch hier unnötige Redraws vermeidet. Beim direkten Vergleich zwischen 'Smart Redraw' und 'TOS Redraw', was hier durchaus im wörtlichen Sinn als Gegenteil zu verstehen ist, zeigt sich in ersterem Fall ein wesentlich schnellerer, ruhigerer und saubererer Bildschirmaufbau, der durchaus mit dem Macintosh-System konkurrieren kann und unter TOS selbst mit Blitter und 68040 Prozessor in dieser Form nicht möglich wäre. Daher wird dringend empfohlen, diese elegante Lösung nicht durch Ausnutzen undokumentierter Eigenschaften des TOS zunichte zu machen.
Sollten sie Programme benutzen, die das oben beschriebene Fehlverhalten aufweisen, so sollten sie wie folgt verfahren:
Querverweis: Smart-Redraw ausschalten GEM Style-Guidelines
MagiC
Allgemeines zum Shutdown
Der Task-Manager in MagiC