Tobias1983 hat geschrieben:Gehen wir mal davon aus ich würde ein eigenes Betriebssystem programmieren.
Unter diesem funktioniert kein OpenGL und kein DirectX somit kann ich beides nicht verwenden.
Und müsste etwas komplett eigenes bauen.
Dein Betriebssystem würde dem Treiber der Grafikkarte sagen, was er auf den Bildschirm zeichnen soll. Wie die Hardware das umsetzt, und dass ein Treiber zur Verfügung steht, ist eine Sache von dessen Hersteller. Es liegt also ganz einfach außerhalb deines Verantwortungsbereichs. Bei GDI war es afaik so, dass jedes angeschlossene Gerät (egal, ob Bildschirm oder Drucker) zumindest die Funktion unterstützen musste, an einer bestimmten Position einen Punkt mit einer bestimmten Farbe auszugeben. Darauf aufbauend konnten von GDI dann Linien gezeichnet werden, schließlich auch Formen und Texte. (Korrigiert mich, wenn ich mich irre).
Wenn es keine Treiber gibt, unterstützt jede Grafikkarte zumindest Default-Modi wie den Textmodus, den du siehst, bevor dein Rechner beim Booten das Betriebssystem startet. (Sonst würde dann ja noch nichts angezeigt werden können.) Wie das genau funktioniert ist schon komplexer, aber vor allem ist es für heutige Programmierung
völlig belanglos ;) Selbst, wenn du das entsprechende Wissen hättest, könntest du es nur sehr schwer einsetzen (z.B. indem du einen eigenen Treiber programmierst), weil das Betriebssystem die Hardware vor jedem nicht aus den Annalen erfolgenden Zugriff schützt.
Tobias1983 hat geschrieben:Wird dann z.B. wenn sich ein Text änedrt nur dieser Text dargestellt oder der ganze Bildschirm.
Und wie wird berechtnet was davon dargestellt werden soll.
Auf Windows bis Vista nur die geänderten Elemente, ab Aeroglass alles (weil es auf heutigen GPUs flotter ist und der Bildschirm nicht mehr zumüllt, wenn was hängt). Da jedes Fenster eine Position hat, und jeder Text intern als Fenster gehandhabt wird (wie auch jeder Button und jedes Bild), entspricht die Fläche, die man aktualisiert, der Fensterposition in der linken oberen und Fensterposition + Fenstergröße in der rechten unteren Ecke.
Aber ganz egal, wie du das Pixel-Array, das intern deinen Bildschirm repräsentiert, veränderst – die Hardware behält immer eine Kopie davon, weil der Bildschirm je nach Wiederholrate sowieso 60 bis 120 × pro Sekunde nochmal mit dem kompletten Videoignal beschrieben werden muss.
========
Wie ein Pixel auf dem Bildschirm erscheint hängt also in erster Linie vom Betriebssystem (und dessen API, wie z.B. Direct3D) ab, das den Treibern sagt, was zu rendern ist. Die Treiber schicken Befehle an die Hardware. Die Hardware schickt ein Videosignal an den Monitor.
Was im Betriebssystem geschieht, ist schon zu komplex, um sich anfangs damit zu befassen (User-Mode vs. Kernel-Mode etc.) und ist für 99% der Programme egal. Was im Treiber geschieht, ist zehnmal komplexer und zu 99,99% für eine Anwendung egal. Was in der Hardware geschieht, ist weitere 10× komplexer und für 99,9999% der Anwendungen egal.
Wenn du also nicht auf 20 Jahre alter Hardware ohne Betriebssystem programmierst oder deine Anwendung die eine, missionskritische Anwendung aus einer Million werden wird, ist es Zeitverschwendung, sich mit sowas zu befassen. Nicht nur, weil es von Betriebssystem zu Betriebssystem, von Treiberversion zu Treiberversion und von GPU-Modell zu GPU-Modell unterschiedlich ist, sondern weil du daraus nichts über gutes Programm-Design lernst. Einen groben Eindruck zu haben, wie sowas vonstatten geht, ist natürlich nie verkehrt (sonst hätte ich das ja auch nicht geschrieben :) ) und das Wissen um die ungefähre Arbeitsweise der GPU wird bei Optimierungen sehr nützlich – aber solange du noch nichts zum Darstellen hast, nützt dir das alles nichts.
Gruß, Ky