Programmiererecke - Was dem einen sin Ul...

Über Grow- und Shrink-Boxen ist in letzter Zeit viel und leider unergiebig diskutiert worden. Mit unserem Programm messen Sie den Geschwindigkeitsgewinn beim Ausschalten der Boxen selbst.

Disput auf der CeBIT: Grow- und Shrink-Boxen abschalten, um eine höhere Performance bei der Bildschirmausgabe zu erzielen? Diese Boxen haben primär natürlich erst einmal kosmetischen Charakter, soviel ist unbestritten. Doch wer sich auf das Abenteuer einläßt, eine weitverbreitete grafische Benutzeroberfläche wie GEM zu diskutieren, muß sich die Frage gefallen lassen, ob nicht das ganze GEM-System als kosmetisch anzusehen ist. Sicher - das Erscheinen oder Verschwinden der Boxen hat oberflächlich gesehen keine Funktion. Vom Standpunkt der Human Interface aus gesehen gibt es dennoch eine Begründung dafür: Grow- und Shrink-Boxen zeigen dem Benutzer an, daß neue Informationen für ihn auf dem Bildschirm erscheinen oder alte verschwinden.

Beim reinen Verschieben von Fenstern oder Dialogboxen, die solches zulassen, werden hingegen keine Grow- oder Shrink-Boxen benutzt. Dementsprechend benutzen die meisten Programmierer diese Funktionen, obwohl sie darauf problemlos auch hätten verzichten können.

Das Abschalten der Grow- und Shrink-Boxen wirft zwei Fragen auf. zum einen, ob es sinnvoll sei, eine Arbeit, die eigentlich dem Programmierer obliegt, dem Benutzer zu übertragen.

Zum anderen, ob es nicht effektivere Wege zur Steigerung der Screenperformance gegeben hätte. Beispielsweise durch eine komplette Neuprogrammierung von AES und VDI, wie dies im jungen Screenspeeder »NVDI« der Fall ist. Damit hätte man den Vorwurf, mit Benchmark-Programmen zu blenden, einfach beiseite geräumt.

Wie dem auch sei, in dieser Ausgabe des ST-Magazins stellen wir ein kurzes Assembler-Programm vor, das in jedem TOS die Grow- und Shrink-Boxen ab- und wieder anschaltet. Damit können Sie sich selbst ein Bild über den Geschwindigkeitsgewinn machen. Grundsätzlich sollte man darauf verzichten, ein System durch Anschalten vorhandener Funktionen zu beschneiden, doch urteilen Sie selbst.

Unser Assembler-Programm installiert sich beim Start vom Desktop aus im AES- und VDI-Trap. Dort wartet es auf Aufrufe der Funktionen »graf_growbox()« (AES 73), »graf_shrinkbox()« (AES 74) und »form_dial()« (AES 51). Letztere wird nur beachtet, wenn als Parameter »FMDGROW« (1) oder »FMDSHRINK« (2) gewählt wurden. Bei Aufruf dieser Funktionen wird einfach der Return-Wert in int_out auf einen Wert ungleich Null gesetzt (Null hätte einen Fehler bedeutet) und zurück zum Programm gesprungen.

Zur Installation wird wie gewohnt das XBRA-Verfahren benutzt, das es erlaubt, das Programm durch mehrfaches Starten anzuschalten oder zu deaktivieren, ohne daß dabei jedesmal Speicher belegt würde.

Die gängigen Performance-Tester zeigen bei abgeschalteten Grow- und Shrink-Boxen etwa 70 bis 90 Prozent höhere Geschwindigkeit an. Der Atari- und DRI-Desktop wird leider nicht beschleunigt, da dieses Programm nicht über den normalen AES-Handler seine Funktionen aufruft, sondern direkt ins AES springt. Nicht gerade die feine englische Programmiertechnik, zumal der dadurch erzielte Geschwindigkeitsgewinn wahrscheinlich minimal ist.

Programme wie beispielsweise »Quick Index« oder das Resource Construction Set von Digital Research zeigen sich in der GEM-Darstellung durch den Funktions-Cut deutlich schneller. Somit wären solche Benchmark-Werte fürs erste relativiert. Die Programme werden schneller - jedoch weniger durch geschickte VDIOptimierung als vielmehr eine Beschneidung von OS-Routinen.

Die Programmiererecke wäre ziemlich dröge ohne den sich wachsender Beliebtheit erfreuenden »wind_update()«-Part.

Wind_update (): neue Geheimnisse aus den Innereien des GEM

Bereits in unserer Januar-Ausgabe haben wir darauf hingewiesen, daß eine Schachtelung von wind_update()-Aufrufen GEM keinerlei Probleme bereitet [1]. Das kann im Einzelfall äußerst praktisch für den Programmierer sein. Wie tief diese Schachtelung allerdings gehen darf, war bislang unbekannt.

Da Atari keinerlei Statement zu diesem Thema abzuringen war, mußte uns ein Blick ins TOS weiterhelfen. Markus Fritze, Programmierer des »Turboass«, hat kürzlich herausgefunden, daß GEM für beide Parameter (sowohl xxx_UPDATE« als auch »xxx_MCTRL«) jeweils einen "short«-Zähler (16 Bit) mitlaufen läßt und diesen sogar gegen Unterlauf schützt. Da diese Features - wie überhaupt das meiste in Sachen »wind_update()« - nicht von Atari dokumentiert sind, sollte man sich auf den Unterlauf-Fehlerfänger besser nicht verlassen. Überhaupt sollte man sich nie auf undokumentierte Features eines Betriebssystems verlassen, da man nie weiß, ob sie in der nächsten Revision noch vorhanden sind. Dafür kann fortan relativ sicher die »wind_update()«-Funktion geschachtelt werden den »short«-Wertebereich dürfte die Schachtelung in der Praxis niemals überschreiten.

Auch war bislang wenig bekannt, daß der Parameter »BEG_MCTRL« automatisch auch ein »BEG_UPDATE« ausführt. Zusätzlich meldet er den gesamten Bildschirm als Fenster des aufrufenden Programms oder Accessory an und erlaubt damit alleinigen Zugriff auf Maus und Keyboard (dies war vor dem Aufruf der Applikation des obersten Fensters vorenthalten). Mausklicks auf Fensterelementen werden künftig nicht mehr vom Screen-Manager ausgewertet, sondern als einfache Button-Events an den »MCTRL«-Prozeß weitergeleitet. Nach Beendigung des Screen-Vorgangs via »END_MCTRL« wird der vorherige Zustand beider Zähler und des Fenster-Handlings wiederhergestellt.

(uw)

Literatur:

[1] L. Prüßner, »Nachschlag mit Trick«, ST-Magazin 1/91, Seiten 118f., Markt & Technik Verlag

Dieses Programm schaltet die Boxen aus und ein.


Laurenz Prüßner
Links

Copyright-Bestimmungen: siehe Über diese Seite
Classic Computer Magazines
[ Join Now | Ring Hub | Random | << Prev | Next >> ]