Double Buffering

Das geht, machen u.a. zahlreiche Spiele so. Nur das Color-RAM kann man nicht umschalten, aber das weißt Du vermutlich.

Ja klar. Wobei so oder so nichts "flackert", selbst wenn Du im Bild umschaltest, Du bekommst nur ggf. etwas "Tearing" (=> Google), was aber in UIs kaum eine Rolle spielen wird.

Du hast ja ein Single-Task-System, auch ohne TCP-Stack o.ä. im Hintergrund. D.h. wenn die GUI zeichnet, kannst du dich darauf verlassen, dass immer die exakt gleichen Ressourcen (=Anzahl Rasterzeilen) zur Verfügung stehen. Deshalb kannst du theoretisch ausknobeln, wie viele Rasterzeilen deine GUI im schlimmsten Fall fürs Neuzeichnen bzw. Kopieren benötigt und ob es eine Y-Position (Rasterzeile) gibt, an der du den Kopiervorgang starten kannst ohne dass sich Kopiervorgang und Rasterstrahl je in die Quere kommen. Vielleicht brauchst du gar kein Double-Buffering...

Alternativ: Die Interrupt-Routine wird um einen Einsprung bei der ersten "unsichtbaren" Rasterzeile erweitert, der nichts macht außer das "Bildwechsel!"-Flag zu überprüfen. Wenn gesetzt, wird es gelöscht und auf den anderen Bildschirm umgeschaltet. Die GUI zeichnet ab jetzt Änderungen in den Buffer, setzt das Flag "Bildwechsel!", wartet bis es wieder gelöscht ist - der Interrupt hat jetzt flickerfrei auf den neuen Screen gewechselt - und kopiert dann den aktuellen Bildschirm in den alten Bildschirm. Das wirkt "schneller", weil die GUI maximal schnell reagiert - und wenn der Mauszeiger vom Interrupt gehandhabt wird, merkt der Nutzer von dem Zeitverlust durch den anschließenden Kopiervorgang gar nichts, weil er ja i.d.R. erst mal wieder mit dem Bewegen des Mauszeigers auf ein neues Ziel (Menü-Eintrag, anderes Fenster...) beschäftigt ist.

Ich sehe aber ehrlich gesagt keinen Bedarf dafür, die GUI "schneller" zu machen - das ist m.E. schon ausreichend schnell. Oder ich habe die eine langsame Aktion einfach noch nicht gefunden.

Quote from WebFritzi

Ok. Allerdings ist mir aufgefallen, dass ich nach dem Umschalten trotzdem noch den Inhalt kopieren müsste, damit Buffer und Screen wieder identisch sind

Eigentlich schließe ich mich den anderen an: Für den Zweck einer GUI dürfte das nicht so eine Rolle spielen. Bei Windows auf alten PCs konnte man dem Bildschirmaufbau auch zugucken, und es hat nicht gestört.

Wenn es aus Spaß perfekt werden soll:

Unter Umständen musst Du nicht umkopieren: Screen und Buffer können einfach ihre Rollen tauschen. Wenn es so programmiert ist, dass alle Ausgaben ohne feste Adresse laufen, dann ist das gar nicht so schlimm, Screenausgaben sind eh bequem gerne mit (zp),y.

Und ja, das Umschalten dann an bester Rasterzeile machen, das Hauptprogramm setzt nach dem Zeichnen nur ein Flag, dass die Rasterroutine das tun soll.

Der Teufel steckt aber im Detail.

- Eine GUI will ihre Fensterchen über den gerade aktuellen Bildschirminhalt malen. Der Buffer enthält aber bestenfalls einen veralteten Inhalt. Dann ist ein zusätzliches Umkopieren doch wieder eine gute Lösung.

- Wenn das Hauptprogramm ein Fenster fertiggemalt und das Kommando zum Umschalten gegeben hat, dann wird nicht sofort, sondern irgendwann in näherer Zukunft umgeschaltet. Bis dahin gibt es keinen freien Bildschirm zum Zeichnen. Entweder musst Du das Zeichnen so lange sperren, oder Du machst gleich Triple-Buffering: Reihum wird 1 Screen aktuell angezeigt, einer soll angezeigt werden, einer ist frei zum Malen.

Quote from WebFritzi

1024 Kopierdurchgänge sparen.

1000

Hat sich mal jemand das FC3-Menüsystem angeschaut bzw. nachgesehen, wie das funktioniert? Das sieht schick aus, und man kann sogar von anderen Fenstern verdeckte Fenster im Hintergrund verschieben.