GDI und GDI+ ist ja eine geräteunabhängige Schnittstelle um Text in
verschiedenen Schriftarten, sowie Fenster, GUI Elemente, Linien,
Bezierkurven und sonstige Grafikelemente auf den verschiedensten
Geräten, von der Grafikkarte zum Drucker, zum Plotter und wahrscheinlich
auch auf dem Faxgerät ausgeben zu können.
Dass man Text, den man in seiner Textverarbeitung sieht, genauso
ausdrucken können wollte, wie er auf dem Bildschirm angezeigt wird, ist
klar.
Aber dennoch stellt sich die Frage, warum GDI gleichzeitig Grafikkarten
UND Drucker bedienen können musste.
Hätte es nicht genügt, einfach die Dokumente als bspw. Postscript
auszugeben und dann bevor das ganze an die Grafikkarte (oder den
Drucker) geschickt wird, entsprechend noch einmal für das entsprechende
Geräte falls erforderlich in einer weiteren Stufe nachzubearbeiten. Die
meisten Drucker konnten ja schließlich schon PS.
Was ich nämlich nie verstanden habe ist der Punkt, warum der Drucker die
nicht dokumentenrelevanten Sachen eines Desktops ausdrucken können
sollte.
Also die Fenster, die Buttons und sonstige GUI Elemente?
Warum wurde auch das für den Drucker abstrahiert und der Drucker dazu
befähigt, somit auch die GUI auszudrucken?
Im Prinzip hätte es ja genügt von der GUI einen hochauflösenden
Screenshot zu erstellen und den dann an den Drucker zu schicken.
Letzten Endes dürfte GDI so für alle Geräteklassen unnötig komplex
geworden sein, was dann wieder bei der Ausgabe auf dem Bildschirm dazu
führte, dass diese langsamer war, als nötig, oder die Treiber komplexer
wurden und für bspw. Spiele brauchte man dann so APIs wie DirectX, mit
dem man dann an GDI vorbei die Daten wieder direkt an die Grafikkarte
schicken konnte.
Das X Window System oder Wayland hat so etwas, wenn ich mich nicht irre,
ja auch nicht.
Ob das so auch beim Mac gemacht wurde, wäre auch noch interessant.
Eine Geräteabstraktion macht in vielen Fällen sicherlich Sinn, aber
gerade eine Grafikkarte und ein Drucker sind doch so unterschiedlich,
dass man sich fragt, wozu das nötig ist, dafür eine vereinte
Schnittstelle zu haben?
michael_ schrieb:> Bist du aus einem schlimmen Traum erwacht?> Warum, Warum, ...> Fragen machen dumm!
Habe ich dich wieder mit etwas konfrontiert, dass dir kognitiv zu hoch
ist? Weswegen du jetzt so gereizt bist?
Stell dir mal vor, es gibt sogar Leute, die wollen wissen, wieviele
Stellen die Zahl Pi hat und treiben daher einen riesen aufwand, das per
Computer herauszufinden.
Ist dir natürlich auch zu hoch, verstehe. Aber so ist das halt nunmal.
Es geht im Leben eben nicht nur um deinen Acker, deinen Esel und deine
Kühe, sondern auch um ganz andere Frage, die du dir gar nicht vorstellen
kannst.
Nano schrieb:> GDI und GDI+ ist ja eine geräteunabhängige Schnittstelle um Text in> verschiedenen Schriftarten, sowie Fenster, GUI Elemente, Linien,> Bezierkurven und sonstige Grafikelemente auf den verschiedensten> Geräten, von der Grafikkarte zum Drucker, zum Plotter und wahrscheinlich> auch auf dem Faxgerät ausgeben zu können.
... und in eine Datei schreiben zu können - das ist dann Windows Meta
File (WMF) bzw EMF Enhanced Metafile.
> Aber dennoch stellt sich die Frage, warum GDI gleichzeitig Grafikkarten> UND Drucker bedienen können musste.
Das war eben der Weg, Dokumente geräte- und auflösungsunabhängig zu
rendern.
> Hätte es nicht genügt, einfach die Dokumente als bspw. Postscript> auszugeben und dann bevor das ganze an die Grafikkarte (oder den> Drucker) geschickt wird, entsprechend noch einmal für das entsprechende> Geräte falls erforderlich in einer weiteren Stufe nachzubearbeiten. Die> meisten Drucker konnten ja schließlich schon PS.
Nein. Das ganze ist entstanden, als es im Wesentlichen nur Nadeldrucker
gab. Postscript war noch nicht erfunden, es war extrem teuer, und es war
prozessorintensiv. NeXT hatte Display Postscript, aber das war nicht
schnell.
> Im Prinzip hätte es ja genügt von der GUI einen hochauflösenden> Screenshot zu erstellen und den dann an den Drucker zu schicken.
So wurde es auf dem Amiga gemacht, und das sah immer scheiße aus, weil
die Rasterfonts eben nur für die Bildschirmauflösung da waren, aber nie
für die Druckerauflösung. Und langsam war es auch noch, eben weil es
Pixelorientiert war und nicht vektororientiert und von anfang an
auflösungsunabhängig designed.
> Letzten Endes dürfte GDI so für alle Geräteklassen unnötig komplex> geworden sein, was dann wieder bei der Ausgabe auf dem Bildschirm dazu> führte, dass diese langsamer war, als nötig, oder die Treiber komplexer> wurden und für bspw. Spiele brauchte man dann so APIs wie DirectX, mit> dem man dann an GDI vorbei die Daten wieder direkt an die Grafikkarte> schicken konnte.
GDI ist für 2D geschaffen wurden. 3D-Rendering wird nicht abgebildet,
und dafür braucht es einfach andere APIs.
> Das X Window System oder Wayland hat so etwas, wenn ich mich nicht irre,> ja auch nicht.
Doch, sowas gab es auch dafür.
https://www.x.org/archive/X11R6.9.0/doc/html/Xprt.1.html> Ob das so auch beim Mac gemacht wurde, wäre auch noch interessant.
Ja, da hat Bill das Konzept schließlich geklaut.
> Eine Geräteabstraktion macht in vielen Fällen sicherlich Sinn, aber> gerade eine Grafikkarte und ein Drucker sind doch so unterschiedlich,> dass man sich fragt, wozu das nötig ist, dafür eine vereinte> Schnittstelle zu haben?
Für 2D passt das schon.
fchk
Nano schrieb:> es gibt sogar Leute, die wollen wissen, wieviele> Stellen die Zahl Pi
und damit nur beweisen dass es eben doch dumme Fragen gibt.
Nano schrieb:> Ist dir natürlich auch zu hoch
Du bist derjenige dem was zu hoch ist - nämlich was irrationale Zahlen
sind.
Georg
Frank K. schrieb:>> Im Prinzip hätte es ja genügt von der GUI einen hochauflösenden>> Screenshot zu erstellen und den dann an den Drucker zu schicken.>> So wurde es auf dem Amiga gemacht, und das sah immer scheiße aus, weil> die Rasterfonts eben nur für die Bildschirmauflösung da waren, aber nie> für die Druckerauflösung. Und langsam war es auch noch, eben weil es> Pixelorientiert war und nicht vektororientiert und von anfang an> auflösungsunabhängig designed.
Das waren aber nur GUIs, ich meine damit ja nicht die Textdokumente.
>>> Letzten Endes dürfte GDI so für alle Geräteklassen unnötig komplex>> geworden sein, was dann wieder bei der Ausgabe auf dem Bildschirm dazu>> führte, dass diese langsamer war, als nötig, oder die Treiber komplexer>> wurden und für bspw. Spiele brauchte man dann so APIs wie DirectX, mit>> dem man dann an GDI vorbei die Daten wieder direkt an die Grafikkarte>> schicken konnte.>> GDI ist für 2D geschaffen wurden. 3D-Rendering wird nicht abgebildet,> und dafür braucht es einfach andere APIs.
DirectX ist nicht nur 3d, sondern hat auch 2D. Mit DirectDraw und WinG
fing das an und zumindest ersteres ist in DirectX gewandert.
DirectX ist ja nur ein Oberbegriff für viele APIs.
Z.B. DirectPlay, Direct2d, DirectDraw und das, an das alle immer zuerst
denken Direct3d.
Und mit DirectDraw könnte man halt auch GUIs erstellen und das eben in
viel schneller als über GDI, eben weil DirectDraw eben für 2d Spiele
entwickelt wurde.
Und wenn ich mich nicht irre, gibt es dafür jetzt Direct2d.
>> Das X Window System oder Wayland hat so etwas, wenn ich mich nicht irre,>> ja auch nicht.>> Doch, sowas gab es auch dafür.>> https://www.x.org/archive/X11R6.9.0/doc/html/Xprt.1.html
Das ist etwas anderes. Das muss explizit von den Anwendungen benutzt
werden.
Das ist keine Umleitung der Grafikausgabe in einen Drucker.
>>> Ob das so auch beim Mac gemacht wurde, wäre auch noch interessant.>> Ja, da hat Bill das Konzept schließlich geklaut.
Belege? Quelle?
GDI gibt's schon seit Windows 1.0. Da gab es noch keinen Mac, da hat
Apple gerade einmal Lisa erfunden.
Und wie soll das auf dem Mac heißen?
>> Eine Geräteabstraktion macht in vielen Fällen sicherlich Sinn, aber>> gerade eine Grafikkarte und ein Drucker sind doch so unterschiedlich,>> dass man sich fragt, wozu das nötig ist, dafür eine vereinte>> Schnittstelle zu haben?>> Für 2D passt das schon.
Das hat so schlecht gepasst, dass man für Windows WinG und DirectDraw
erschaffen musste, damit man an dem lahmen GDI vorbei möglichst schnell
Grafiken auf den Bildschirm zeichnen konnte.
Klar, heute ist das egal, die CPUs sind ja leistungsfähig genug und die
GPUs für GDI optimiert bzw. waren sie das. Heute gibt's ja GDI+, so dass
man das eher durch die 3d Pipline der GPU schiebt.
Georg schrieb:> Nano schrieb:>> es gibt sogar Leute, die wollen wissen, wieviele>> Stellen die Zahl Pi>> und damit nur beweisen dass es eben doch dumme Fragen gibt.>> Nano schrieb:>> Ist dir natürlich auch zu hoch>> Du bist derjenige dem was zu hoch ist - nämlich was irrationale Zahlen> sind.>> Georg
Bla, bla, bla, als ob du aus 2 Zeilen Text irgendwas deuten könntest.
Kaffeesatzlesen und Glaskugelschauen ist wohl dein Hobby.
Es ist nun einmal Fakt, dass man bei der Zahl PI daran forscht, wie viel
Stellen nach dem Komma diese Zahl hat, auch wenn du mit deinem
Flacherdlerglauben da deine Probeleme hast.
Nano schrieb:> Warum wurde auch das für den Drucker abstrahiert und der Drucker dazu> befähigt, somit auch die GUI
Mit Namen ist das so eine Sache, die können zu Missverständnissen
führen. Während eine Kalbsleberwurst Kalbfleisch enthält, schlachtet man
für eine Bauernleberwurst keine Bauern. Bei PCL- und GDI-Druckern ist
das ähnlich.
Denn bist völlig auf dem falschen Dampfer. Ein GDI Drucker kriegt über
seine Schnittstelle eine Art proprietärer Bitmap geliefert. Der Treiber
hingegen könnte versucht sein, das GDI zu verwenden, um sie zu erzeugen,
denn irgendwer muss aus Buchstaben und Fonts Punkte machen. Und das kann
das GDI sowieso schon.
(prx) A. K. schrieb:> Nano schrieb:>> Warum wurde auch das für den Drucker abstrahiert und der Drucker dazu>> befähigt, somit auch die GUI>> Du bist völlig auf dem falschen Dampfer. Ein GDI Drucker kriegt über> seine Schnittstelle eine Art proprietärer Bitmap geliefert. Der Treiber> hingegen könnte versucht sein, das GDI zu verwenden, um sie zu erzeugen,> denn irgendwer muss aus Buchstaben und Fonts Punkte machen. Und das kann> das GDI sowieso schon.
Dass der Treiber das GDI verwendet, davon gehe ich aus.
Anwendung -> GDI -> Druckertreiber -> Drucker
Anwendung -> GDI -> Grafiktreiber -> Grafikkarte
Was ich mich aber Frage ist der Punkt zwischen Anwendung und GDI.
Die Anwendung verarbeitet bspw. intern ein Textdokument, man könnte das
also auch so lösen:
Anwendung
|
Text + GUI
|
|- Dokument zu Drucker API -> Druckertreiber -> Drucker
|- Text + Gui zu Grafikapi -> Grafiktreiber -> Grafikkarte
Beim Punkt "Dokument zu Drucker API" bräuchte man die GUI nämlich nicht.
Was man aber nun hat ist eher so etwas:
Anwendung
|
Text + GUI realisiert mit GDI
|
|- Druckertreiber -> Drucker
|- Grafiktreibher -> Drucker
> Beim Punkt "Dokument zu Drucker API" bräuchte man die GUI nämlich nicht.
Brauchst du ja auch in deinem ersten Beispiel nicht. Du scheinst GUI
und GDI synonym zu benutzen - das ist aber nicht der Fall. Das sind
zwei unterschiedliche Layer. GDI ist die Low-Level-Grafik-API zum
"malen" von Texten, Linien, Flächen, Images, etc (wie auch Postscript
oder PDF). Als Backend kann u.A. der Bildschirm, ein Drucker, oder auch
eine Datei (WMF) ausgewählt werden.
GDI kennt keine Buttons etc. Das erledigt die darüber liegende GUI und
benutzt dazu GDI zum Malen seiner GUI-Elemente. Die Anwendung benutzt
natürlich auch GDI, um das Dokument (in einem von der GUI
bereitgestellen Bereich) zu malen. Da GDI aber geräteunabhängig ist,
kann der gleiche Code das Dokument genauso gut auf den Drucker "malen".
Eine API für Anzeige und Drucken - so wie du das auch mit Postscript
haben wolltest, nur halt mit GDI.
Btw, WMF ist wirklich nur eine serialisierte Form der GDI-Aufrufe. Zum
Drucken wird die Datei einfach, mit einem Drucker als Backend,
abgespielt. Keinerlei "GUI" ist dabei beteiligt.
Nano schrieb:> Es ist nun einmal Fakt, dass man bei der Zahl PI daran forscht, wie viel> Stellen nach dem Komma diese Zahl hat,
Nein. Man muss nicht danach forschen, man weiß es bereits: Unendlich
viele.
Nano schrieb:> GDI und GDI+ ist ja eine geräteunabhängige Schnittstelle
Ja.
> Hätte es nicht genügt, einfach die Dokumente als bspw. Postscript> auszugeben und dann bevor das ganze an die Grafikkarte (oder den> Drucker) geschickt wird, entsprechend noch einmal für das entsprechende> Geräte falls erforderlich in einer weiteren Stufe nachzubearbeiten. Die> meisten Drucker konnten ja schließlich schon PS.
Nein.
Der Hauptgrund für die Existenz von GDI-Druckern war: Kostenersparnis.
Das Konzept ermöglicht es nämlich, im Drucker mit sehr viel weniger
Hardware auszukommen, sprich: die Drucker billiger zu machen.
Sie brauchen nicht die Rechenleistung zu haben, die nötig ist, um in
akzeptabler Zeit aus Vektordaten eine Bitmap zu rastern und, noch viel
wichtiger: sie brauchen nicht den Speicher zu haben, um eine ganze Seite
in Druckerauflösung zu beherbergen. Speicher war damals(tm) nämlich noch
extrem teuer.
Die GDI-Drucker benutzten nun einfach die ohnehin vorhandene Hardware
des Host-PC. Der Drucker selber brauchte bloß noch die fertigen
Bitmapdaten nach Bedarf (also Druckfortschritt) abzurufen.
Und es stimmt übrigens auch nicht, dass die meisten Drucker damals schon
PS konnten. Das konnten sie aus genannten Gründen in ihrer überwiegenden
Mehrheit eben gerade nicht.
Und was nun GDI betrifft: Man hätte sicher auch einen anderen Renderer
verwenden können, aber warum sollte man, wenn das GDI nunmal bereits
existiert und alle benötigten Fähigkeiten besitzt? Das wäre doch Unsinn
gewesen.
Insbesondere deshalb, weil ja die Programme es sowieso benutzt haben, um
die Grafik darzustellen. Man konnte nun mit demselben, bereits
vorhandenen Code auch den Drucker füttern. Dazu musste man bloß die
Ausgabe auf einen anderen DC (device context) machen und fertig.
Sprich: es gab nicht nur für den Druckerhersteller eine Kostenersparnis,
sondern auch für alle Softwareanbieter.
foobar schrieb:>> Beim Punkt "Dokument zu Drucker API" bräuchte man die GUI nämlich nicht.>> Brauchst du ja auch in deinem ersten Beispiel nicht. Du scheinst GUI> und GDI synonym zu benutzen - das ist aber nicht der Fall. Das sind> zwei unterschiedliche Layer. GDI ist die Low-Level-Grafik-API zum> "malen" von Texten, Linien, Flächen, Images, etc (wie auch Postscript> oder PDF). Als Backend kann u.A. der Bildschirm, ein Drucker, oder auch> eine Datei (WMF) ausgewählt werden.
Das habe ich schon verstanden.
Aber eine GUI kann man ohne den Umweg über Objekte, wie sie bei GDI nun
einmal benutzt werden, viel effizienter und schneller zeichnen.
Vor der Zeit der 2d Beschleuniger, wo man noch alles in Software machen
musste, hätte das also bedeutet, dass man direkt in den Speicher der
Grafikkarte hätte schreiben können.
Und beim Verschieben von Bildelementen hätte man ganze Bereiche
überschreiben können ohne alles neu Zeichnen zu müssen.
D.h. GDI bremst die ganze Grafikausgabe aus und das nur, damit man auf
den Drucker GUI Oberflächen ausdrucken kann?
Es hat einen guten Grund, warum Windows anfangs für Spiele stark
gemieden wurde und der Umweg alles über GDI zeichnen zu müssen war
dieser Grund.
Man hätte also, wenn man Fenster und GUI Elemente auf dem Bildschirm
anzeigen will, das ohne GDI viel schneller und effizienter machen
können.
> GDI kennt keine Buttons etc. Das erledigt die darüber liegende GUI und> benutzt dazu GDI zum Malen seiner GUI-Elemente.
Schon klar. Aber siehe oben.
Der wesentliche Punkt meiner Frage ist ja, warum der Drucker befähigt
sein muss, die GUI auch ganz genau ausgeben zu können. Es hätte ja
völlig genügt, wenn man unter der Haube einfach eine Druckerapi für
Dokumente entwickelt hätte, die dann mit dem Druckertreiber spricht.
> Da GDI aber geräteunabhängig ist,> kann der gleiche Code das Dokument genauso gut auf den Drucker "malen".
Das ist klar. Nur war halt meine Frage warum der Drucker so etwas können
müssen sollen. Eigentlich druckt man auf einem Drucker nur seine
Dokumente aus und nicht den "Bildschirm".
> Eine API für Anzeige und Drucken - so wie du das auch mit Postscript> haben wolltest, nur halt mit GDI.
Ich wollte eigentlich getrennte APIs für die Anzeige und das Drucken und
beides dann für seine Ausgabegeräteklasse entpsrechend optimiert und
somit schnell und effizient.
c-hater schrieb:> Der Hauptgrund für die Existenz von GDI-Druckern war: Kostenersparnis.> Das Konzept ermöglicht es nämlich, im Drucker mit sehr viel weniger> Hardware auszukommen, sprich: die Drucker billiger zu machen.> Sie brauchen nicht die Rechenleistung zu haben, die nötig ist, um in> akzeptabler Zeit aus Vektordaten eine Bitmap zu rastern und, noch viel> wichtiger: sie brauchen nicht den Speicher zu haben, um eine ganze Seite> in Druckerauflösung zu beherbergen. Speicher war damals(tm) nämlich noch> extrem teuer.> Die GDI-Drucker benutzten nun einfach die ohnehin vorhandene Hardware> des Host-PC. Der Drucker selber brauchte bloß noch die fertigen> Bitmapdaten nach Bedarf (also Druckfortschritt) abzurufen.
Okay, das erklärt natürlich warum man PS gemieden hat, aber darum geht
es mir hier eigentlich nicht.
Man hätte ja durchaus eine Druckerapi nur für Drucker und Plottinggeräte
schaffen können, die dann die Drucker genauso in einem simplen
Ausgabeformat anspricht, so dass deren HW billig sein kann.
Der Punkt ist ja, warum man die Grafikausgabe auf dem Bildschirm
ausgebremmst hat, um Druckern zu ermöglichen, dass diese auch die GUI
Elemente genauso ausdrucken können, wie man sie auf dem Bildschirm
sieht.
> Und was nun GDI betrifft: Man hätte sicher auch einen anderen Renderer> verwenden können, aber warum sollte man, wenn das GDI nunmal bereits> existiert und alle benötigten Fähigkeiten besitzt? Das wäre doch Unsinn> gewesen.
Ja, die Frage ist ja eigentlich, warum man das überhaupt ursprünglich so
gemacht hat.
Irgendwie kommt mir das nämlich so vor, als hätte man noch in der
Computerwelt 10 Jahre zuvor gelebt, wo man noch alles auf irgendwelchen
Papiergeräten ausgeben musste, um irgendwas zu sehen.
Oder um es mal ganz Platt auszudrücken.
Würde man von einer 3d Szene einen Screenshot auf Papier bringen wollen,
dann würde man normalerweise einen Screenshot erstellen und an den
Drucker nur eine Rastergrafik senden.
In GDI Logik würde man das aber so nicht machen, man würde die 3d Szene
Rendern um sie dann an den Druckertreiber zu schicken und der wurstelt
mit der großen Datenmenge dann herum, um was einfaches für den Drucker
daraus zu basteln, die dann der Drucker dann am Ende kriegt.
> Insbesondere deshalb, weil ja die Programme es sowieso benutzt haben, um> die Grafik darzustellen. Man konnte nun mit demselben, bereits> vorhandenen Code auch den Drucker füttern. #
Wobei aber die Grafik nun ausgebremst ist.
> Dazu musste man bloß die> Ausgabe auf einen anderen DC (device context) machen und fertig.> Sprich: es gab nicht nur für den Druckerhersteller eine Kostenersparnis,> sondern auch für alle Softwareanbieter.
Letzteres wäre aber zum vielleicht "doppelten" Preis für Microsoft mit
zwei getrennten APIs genauso gegangen. Dann hätten die
Grafikkartenhersteller ihre API und die Druckerhersteller ihre API und
beide APIs hätte MS geliefert.
Der Unterschied wäre aber gewesen, dass die Grafikausgabe viel schneller
und performanter gewesen wäre und für den Drucker hätte man nur das
Drucken von Dokumenten umsetzen müssen.
Nano schrieb:> Aber eine GUI kann man ohne den Umweg über Objekte, wie sie bei GDI nun> einmal benutzt werden, viel effizienter und schneller zeichnen.> Vor der Zeit der 2d Beschleuniger, wo man noch alles in Software machen> musste, hätte das also bedeutet, dass man direkt in den Speicher der> Grafikkarte hätte schreiben können.
So hat man das zu DOS-Zeiten gemacht mit dem deutlichen Nachteil dass
das hardwareabhängig war, d.h. jede Anwendung musste eigene
Zeichenroutinen für viele (damals sehr viel mehr als heute)
verschiedenen Grafikkarten implementieren. Der entscheidende Vorteil von
Windows und ähnlicher Systeme war dass ein einheitliches,
Geräte-/Hersteller unabhängiges API zur Verfügung gestellt wurde gegen
das die Anwendung programmieren kann. Implementierung der
gerätespezifischen Routinen (aka Treiber) war jetzt Aufgabe des
Grafikkartenherstellers der es aber auch nur einmal pro Betriebssystem
machen musste.
Blechbieger schrieb:> Nano schrieb:>> Aber eine GUI kann man ohne den Umweg über Objekte, wie sie bei GDI nun>> einmal benutzt werden, viel effizienter und schneller zeichnen.>> Vor der Zeit der 2d Beschleuniger, wo man noch alles in Software machen>> musste, hätte das also bedeutet, dass man direkt in den Speicher der>> Grafikkarte hätte schreiben können.>> So hat man das zu DOS-Zeiten gemacht mit dem deutlichen Nachteil dass> das hardwareabhängig war,
Nein, DirectDraw und WinG waren hardwareunabhängig und trotzdem viel
schneller als GDI.
> d.h. jede Anwendung musste eigene> Zeichenroutinen für viele (damals sehr viel mehr als heute)> verschiedenen Grafikkarten implementieren.
Wenn GDI nur eine Ansammlung von Zeichenroutinen wäre, dann wäre es ja
schön, aber GDI ist noch viel viel viel Komplexer.
GDI ist mit dem Feuerwehrschlauch durchs Fenster, dann unten an der
Haustür raus, dann durch das Auto, das daneben steht, dann über den Ast
vom Baum um dann endlich auf die Feuerwehrleiter zu kommen, wo der
Feuerwehrmann dann endlich das Wasser auf Feuer spritzen kann.
Nano schrieb:> Der Punkt ist ja, warum man die Grafikausgabe auf dem Bildschirm> ausgebremmst hat, um Druckern zu ermöglichen, dass diese auch die GUI> Elemente genauso ausdrucken können, wie man sie auf dem Bildschirm> sieht.
Das GDI, als Grundlage der Windows-GUI und 2D-Grafik-Anwendungen, musste
von Anfang an in der Lage sein, in eine Bitmap ins RAM zu rendern, ohne
jede Hilfestellung seitens einer Grafikkarte. Einfach weil die
Grafikkarten aus der Entstehungszeit, wie VGA und ET4000, nichts anderes
waren als ein Bildschirmspeicher, der 60x pro Sekunde vollständig zum
Bildschirm repliziert wurde. Mehr konnten die nicht.
Grafikkarten, die in der Lage waren, manche 2D-Operationen autark
durchzuführen, kamen erst später. Sie waren teuer und anfangs
überwiegend im CAD-Bereich verbreitet. Bei solchen Karten wird der
Inhalt der GUI (und alles andere) über die Schnittstelle GDI und den
GPU-Treiber gerendert. Der setzt die GDI-Operationen in die Operationen
der Grafikkarte um. Da wird also nichts ausgebremst.
GDI-Drucker verwenden also bereits bestehende Methoden, ohne irgendwas
zu behindern oder abzubremsen. Der Nachteil ist die proprietäre
Schnittstelle zum Drucker, weshalb sich andere Betriebssysteme zumindest
damals schwer taten. Die Umsetzung der auf anderen Systemen verbreiteten
Zwischensprache Postscript über Ghostscript zur Bitmap war nicht das
Problem, aber wie man die Bitmap zum Drucker kriegt, musste man erst
einmal rausbekommen.
Viel später entstand der Bedarf nach anderen Verfahren, weil das GDI
nicht für 3D taugt und weil der Weg zur GPU kürzer sein muss. Das ist
aber ein anderes Thema.
(prx) A. K. schrieb:> Nano schrieb:>> Der Punkt ist ja, warum man die Grafikausgabe auf dem Bildschirm>> ausgebremmst hat, um Druckern zu ermöglichen, dass diese auch die GUI>> Elemente genauso ausdrucken können, wie man sie auf dem Bildschirm>> sieht.>> Das GDI als Grundlage der Windows-GUI musste von Anfang an in der Lage> sein, in eine Bitmap ins RAM zu rendern, ohne jede Hilfestellung seitens> einer Grafikkarte. Einfach weil die Grafikkarten aus der> Entstehungszeit, wie VGA und ET4000, nichts anderes waren als ein> Bildschirmspeicher, der 60x pro Sekunde vollständig zum Bildschirm> repliziert wurde. Mehr konnten die nicht.
Falsches Thema und komplett auf dem falschen Dampfer!
Das konnte WinG und DirectDraw (bei Software ohne Karte mit 2d
Beschleunigerfunktionen) auch. Der Unterschied ist aber, dass GDI für
jedes Grafikprimitiv ein Objekt erzeugt und noch einen Haufen Ballast
mitbringt. GDI ist und war eben nie schnell. Für Spiele war es so
langsam, dass es absolut unbrauchbar war, damit etwas sinnvolles
performantes hinzubekommen.
Siehe dazu nochmal das Feuerwehrbeispiel oben als Analogie.
> Grafikkarten, die in der Lage waren, manche 2D-Operationen autark> durchzuführen, kamen erst später. Sie waren teuer und anfangs> überwiegend im CAD-Bereich verbreitet. Bei solchen Karten wird der> Inhalt der GUI (und alles andere) über die Schnittstelle GDI und den> GPU-Treiber gerendert. Der setzt die GDI-Operationen in die Operationen> der Grafikkarte um. Da wird also nichts ausgebremst.
Auf "dummen" Karten aber schon. Und die Beschleunigerfunktionen hat man
dann ja genau auf die GDI Operationen optimiert, damit das wenigstens
benutzbar schnell wurde.
Ein Ballast war es dennoch und sieht man recht schnell, wenn man
versucht einen einfachen VESA Treiber und somit VESA Modus zu nutzen, da
hat man diese Beschleungierhilfsmittel nämlich nicht.
Während ein 2d Spiel, das für Direct2d oder WinG geschrieben wurde, dann
immer noch performant wäre, wäre die GDI Lösung elenedig lahm.
> GDI-Drucker verwenden also bereits bestehende Methoden, ohne irgendwas> zu behindern oder abzubremsen.
GDI wurde ja eben gerade so abstrahiert, dass es auch für GDI Drucker
brauchbar war. Daher hat man eben schon eine Ausbremsung auf der
Grafikkartenseite.
(prx) A. K. schrieb:> Viel später entstand der Bedarf nach anderen Verfahren, weil das GDI> nicht für 3D taugt und weil der Weg zur GPU kürzer sein muss. Das ist> aber ein anderes Thema.
Es taugte auch nicht für 2d Spiele, weswegen WinG und DirectDraw
geschaffen wurden.
Frank K. schrieb:> Postscript war noch nicht erfundenhüstel
Postscript dürfte älter sein als Windows … und die 72 dpi
Standardeinheit von Postscript kommt von irgendeinem alten
Apple-Bildschirm – auf diese Weise hatte man "WYSIWIG" gleich mit.
Man hätte erstens an Adobe Lizenzgebühren bezahlen müssen und zweitens
halt für alle nicht-PS-Billigdrucker den Software-Renderer im OS haben
müssen (die allerdings in der Regel eh mehr Rechenleistung hatten als
die zur gleichen Zeit existierenden Embedded-Lösungen in den Druckern).
Liest man das hier durch:
"Each window consumes GDI objects. As the complexity of the window
increases, with additional features such as buttons and images, its GDI
object usage also increases. When too many objects are in use, Windows
is unable to draw any more GDI objects, leading to misbehaving software
and frozen and unresponsive program operation.
...
Windows 9x had a limit of 1,200 total objects; Windows 2000 has a limit
of 16,384 objects; and Windows XP and later have a configurable limit
....
Overflowing GDI capacity can affect Windows itself, preventing new
windows from opening, menus from displaying, and alert boxes from
appearing. The situation can be difficult to clear and can potentially
require a forced reset of the system, since it prevents core system
programs from functioning. "
https://en.wikipedia.org/wiki/Graphics_Device_Interface#Limitations
dann fällt sofort auf, dass hier ein haufen Ballast verwaltet werden
muss und all das nur, damit auch der Drucker GUI Elemente ausdrucken
kann.
Dazu im Vergleich in Schnell:
"DirectDraw (ddraw.dll) is an API that used to be a part of Microsoft's
DirectX API. DirectDraw is used to accelerate rendering of 2D graphics
in applications. DirectDraw also allows applications to run fullscreen
or embedded in a window such as most other MS Windows applications.
...
DirectDraw allows direct access to video memory, hardware overlays,
hardware blitters, and page flipping. Its video memory manager can
manipulate video memory with ease, taking full advantage of the blitting
and color decompression capabilities of different types of display
adapters.
...
DirectDraw is a 2D API. That is, it contains commands for 2D rendering
..."
https://en.wikipedia.org/wiki/DirectDraw
Nano schrieb:> Aber dennoch stellt sich die Frage, warum GDI gleichzeitig Grafikkarten> UND Drucker bedienen können musste.
Nein, die Frage stellt sich nicht, es ist einfach klug.
> Das X Window System oder Wayland hat so etwas, wenn ich mich nicht irre,> ja auch nicht
Daher die Scheiss-unstandardisierte Druckausgabe unter *nix, bis heute
ein Krampf mit Postscript.
> oder die Treiber komplexer wurden
Im Gegenteil, der Code für rasternde Drucker war schon da. Nur für
Plotter musste man ihn neu erfinden, man KONNTE das aber dank der klugen
Treiberstrukturierung auch.
> und für bspw. Spiele brauchte man dann> so APIs wie DirectX, mit dem man dann an GDI vorbei die Daten wieder> direkt an die Grafikkarte schicken konnte.
Nicht wirklich. DirectX ist Krampf. Aus Sicht des Programms beachtet es
die clipping region nicht. Ein Alien in ansonsten sauberer
Graphikumgebung. Dabei gab es im GDI einen guten Mechanismus zum double
buffering bei kleinen Bildänderungen: Bitmaps mit Sprüngen. Also eine
Bitmap, in der nur Pixel 10-15 von Zeile 1-5, Pixel 22-88 von Zeile 4-40
und Pixel 1-500 von Zeile 240-248 drin stecken, codiert als RLE. Und die
wurde nicht nur rasend schnell und flimmerfrei auf den Bildschirm
kopiert, sonder beachtete dabei auch Fenstergrenzen und Überlappungen.
Aber man musste so eine Bitmap selber erstellen. Es gab kein paint in
eine in diesem Format hinterlegte Bitmap. Das hätte man für einfaches
Programmieren von Games auf Systemen ohne Blitter zum GDI hinzufügen
sollen, aber der Code war wohl zu kompliziert. Dabei gibt es mit
sweepline einen recht schnellen Algorithmus dafür.
Auf uralten PC unter Windows 2 bis 3.11 habe ich damit Spiele und
Graphikanimationen programmieren können, die so schnell waren wie
DirectX (was es erst zum Schluss gab). Ein GameOfLife, ein
Sprite-basierendes Game wie auf Apple/Amiga, und man konnte die Bilder
direkt auf den Drucker ausgeben, dank GDI.
NeXT verwendete Postscript auf Drucker und Bildschirm. Das machte die
Sache nicht nur langsamer, sondern war ebenso blöd wegen der
Fenstergrenzen wie DirectX.
Windows, vor allem von 1 bis 3.11, war schon sehr genial, Basis von
allem waren Regions und Atoms. Andere Graphikaufsätze versuchten sich um
deren erst mal unnötig komplex erscheinende Implementierung zu drücken,
und stolperten dafür später in Probleme, die sie damit nicht gehabt
hätten (wie GEM und Amiga).
Als dann Cutler zu Microsoft kam, ging alles den Bach runter.
MaWin schrieb:> Daher die Scheiss-unstandardisierte Druckausgabe unter *nix, bis heute> ein Krampf mit Postscript.
Stellt sich die Frage, wann du das letzte Mal unter Unix einen Drucker
eingerichtet oder benutzt hast. ;-)
Seit Apple Unix macht (das sind nun auch schon 20 Jahre), hat sich da
einiges getan. Bei unserem letzten großen Bürodrucker (so ein Koloss von
Standgerät) in meiner vorigen Firma gab's nur eine Gruppe von Nutzern,
die einen Haufen Firlefanz machen mussten, bis sie endlich drucken
konnten. Einmal darfst du raten, welche Gruppe das war … the times, they
are a-changin'.
@Nano
irgendwie hast du einen falschen zeitlichen Überblick über das was bei
der Einführung der Sachen technisch möglich und sinnvoll war.
Damals konnte man bei der Grafikkarte wählen zwischen hoher Auflösung
und wenig Farbe (2) oder wenig Auflösung und viel Farben (16-256)
Erstes ist gut für Office, letzteres für Spiele.
Gleichzeitig oder gar in einem Fenster ging das nicht.
Zudem hat sich windows stärker um den Speicher gekümmert.
Alles Dinge, die Spieleprogrammiere nicht mochten.
Übrigens ist GDI in PCL-6 eingebettet.
Nano schrieb:> GDI und GDI+ ist ja eine geräteunabhängige Schnittstelle um Text in> verschiedenen Schriftarten, sowie Fenster, GUI Elemente, Linien,> Bezierkurven und sonstige Grafikelemente auf den verschiedensten> Geräten, von der Grafikkarte zum Drucker, zum Plotter und wahrscheinlich> auch auf dem Faxgerät ausgeben zu können.> ...> Was ich nämlich nie verstanden habe ist der Punkt, warum der Drucker die> nicht dokumentenrelevanten Sachen eines Desktops ausdrucken können> sollte.> Also die Fenster, die Buttons und sonstige GUI Elemente?
Kann es sein, dass deine Frage auf einem Missverständnis beruht? Hat
denn das GDI irgendetwas mit GUI-Elementen zu tun?
Ich bin genauso wenig Windows-Experte wie du, aber m.W. werden
GUI-Elemente auf einer höheren Ebene genauso wie jede andere Grafik aus
Linien, Rechtecken, Bitmaps und dergleichen zusammengesetzt, indem die
entsprechenden GDI-Zeichenfunktionen aufgerufen werden.
(prx) A. K. schrieb:> Während eine Kalbsleberwurst Kalbfleisch enthält, schlachtet man> für eine Bauernleberwurst keine Bauern.
Das wollen SIE uns weismachen...
Yalu X. schrieb:> Ich bin genauso wenig Windows-Experte wie du, aber m.W. werden> GUI-Elemente auf einer höheren Ebene genauso wie jede andere Grafik aus> Linien, Rechtecken, Bitmaps und dergleichen zusammengesetzt, indem die> entsprechenden GDI-Zeichenfunktionen aufgerufen werden.
Das ist korrekt.
Wurde auch nicht nur von Microsoft so gemacht, das GEM-Äquivalent hiess
z.B. VDI (mit GDOS), die GUI-Sachen (AES) waren eine Schicht darüber.
Dass so eine hardwareunabhängige Schicht eine praktische Sache ist,
sieht man z.B. daran, dass das auf dem VGA-Monitor angezeigte
Tortendiagramm beim Ausdrucken in DIN A3 nicht zu einem Pixelbrei wird -
ohne dass man sich als Entwickler dafür ein Bein ausreissen muss.
Frank K. schrieb:>> Im Prinzip hätte es ja genügt von der GUI einen hochauflösenden>> Screenshot zu erstellen und den dann an den Drucker zu schicken.>> So wurde es auf dem Amiga gemacht, und das sah immer scheiße aus, weil> die Rasterfonts eben nur für die Bildschirmauflösung da waren, aber nie> für die Druckerauflösung. Und langsam war es auch noch, eben weil es> Pixelorientiert war und nicht vektororientiert und von anfang an> auflösungsunabhängig designed.
Es gab Programme auf dem Amiga, die das so gemacht haben. Da war aber
nicht der Amiga dran Schuld. Es gab sogar Programme, die Postscript
rausschmissen. Und die entsprechenden Fonts zum Rendering für den
Nadeldrucker waren auch vorhanden.
Gruß
Jobst
Nano schrieb:> Im Prinzip hätte es ja genügt von der GUI einen hochauflösenden> Screenshot zu erstellen und den dann an den Drucker zu schicken.
Dazu muss (im Hintergrund) eine hochauflösende Bitmap erstellt werden,
da der Bildschirm selber niedrig auflöst.
Aber genau das macht der Druckertreiber aus den GDI-Befehlen.
Jobst M. schrieb:> Es gab Programme auf dem Amiga, die das so gemacht haben. Da war aber> nicht der Amiga dran Schuld. Es gab sogar Programme, die Postscript> rausschmissen. Und die entsprechenden Fonts zum Rendering für den> Nadeldrucker waren auch vorhanden.
Zusammenfassend: Der Amiga (so geil er ansonsten war) hatte halt einfach
keine Infrastruktur für gerätunabhängige Grafikausgabe. Deswegen
entstand der von dir beschriebene Wildwuchs, dass es jede einzelne
Software irgendwie anderes gefrickelt hat.
Windows hingegen hatte genau das von Anfang an als primäres Design-Ziel
und stellte deshalb eben diese Infrastruktur für alle Anwendungen
bereit. Und der Erfolg war durchschlagend. Siehe eben auch GDI-Drucker.
Diese machten sich die eigentlich für Anwendungen gedachte Infrastruktur
im Treiber zunutze, um Gerätekosten zu sparen.
Wirklich gute Konzepte werden halt praktisch automatisch allgemein
genutzt...
Dirk B. schrieb:> @Nano>> irgendwie hast du einen falschen zeitlichen Überblick über das was bei> der Einführung der Sachen technisch möglich und sinnvoll war.
Nein, habe ich nicht.
> Damals konnte man bei der Grafikkarte wählen zwischen hoher Auflösung> und wenig Farbe (2) oder wenig Auflösung und viel Farben (16-256)> Erstes ist gut für Office, letzteres für Spiele.
Das tut hier gar nichts zur Sache.
> Gleichzeitig oder gar in einem Fenster ging das nicht.
Es ging nicht, weil GDI lahm war. Deswegen hat Microsoft für Windows 3.x
WinG entwickelt und damit ging es dann, weil das dem Spieleprogrammierer
ermöglichte an GDI vorbei die Grafikkarte und deren RAM viel direkter zu
adressieren ohne den Umweg über das lahme GDI, das für Spiele nicht
geeignet war. Aber das habe ich alles schon oben zigmal erwähnt.
> Zudem hat sich windows stärker um den Speicher gekümmert.> Alles Dinge, die Spieleprogrammiere nicht mochten.
Windows 3.x bot ab der Nachreichung von Win32s dem Programmierer an 32
Bit Anwendungen für den Enhanced Mode von Win3.x zu entwickeln und damit
linear den Speicher zu benutzen, das machte das alles für den
Spieleprogrammierer viel einfacher, da er sich nicht mehr um
segmentierten Speicher kümmern musste und auch kein 640 KiB Limit hatte.
Und was noch fehlte war WinG für den schnellen Zugriff auf die
Grafikkarte, was dann von Microsoft nachgereicht wurde.
Ab WinG war Windows 3.x für die Spieleprogrammierung geeignet.
Hier ist ein Video mit ein paar AAA Spielen die entweder nach Windows
3.x portiert wurden oder direkt dafür programmiert wurden, nachdem WinG
zur Verfügung stand: (PS: der Titel des Videos ist irreführend, DirectX
wurde nicht verwendet, sondern WinG, aber das steht auch unter dem
Video)
https://www.youtube.com/watch?v=bDUfLqxuQPs
Nano schrieb:>> Zudem hat sich windows stärker um den Speicher gekümmert.>> Alles Dinge, die Spieleprogrammiere nicht mochten.>> Windows 3.x bot ab der Nachreichung von Win32s dem Programmierer an 32> Bit Anwendungen für den Enhanced Mode von Win3.x zu entwickeln und damit> linear den Speicher zu benutzen, das machte das alles für den> Spieleprogrammierer viel einfacher, da er sich nicht mehr um> segmentierten Speicher kümmern musste und auch kein 640 KiB Limit hatte.> Und was noch fehlte war WinG für den schnellen Zugriff auf die> Grafikkarte, was dann von Microsoft nachgereicht wurde.> Ab WinG war Windows 3.x für die Spieleprogrammierung geeignet.
Ergänzung:
Zudem bot Windows mit WinG für den Spieleprogrammierer noch viel mehr,
als einen linearen Speicherzugriff und Zugriff auf mehr als 640 KiB RAM.
Weitere Vorteile waren noch eine Abstrahierung der Soundkarte und
Eingabegeräte und eine Verringerung der Supportkosten für den
Spielehersteller.
Windows hatte nämlich eine Soundapi, die man nutzen konnte, der
Spieleprogrammierer musste sich somit nicht mehr darum kümmern, für jede
Soundkarte einen eigenen Treiber zu schreiben oder den zu lizensieren.
Das gleiche galt für die Eingabegeräte wie Joystick, Maus, Keyboard und
Gamepad.
Und die Supportkosten waren auch viel geringer, weil der Endanwender zum
starten des Spieles nicht mehr mit der config.sys und autoexec.bat
herumwursteln musste. Windows 3.x bot im enhanced Mode linearen
Speicherzugriff, die 640 KiB Grenze war damit Geschichte und der
Spieleprogrammierer konnte so viel RAM adressieren, wie eben auf dem
Rechner verfügbar war.
Yalu X. schrieb:> Nano schrieb:>> GDI und GDI+ ist ja eine geräteunabhängige Schnittstelle um Text in>> verschiedenen Schriftarten, sowie Fenster, GUI Elemente, Linien,>> Bezierkurven und sonstige Grafikelemente auf den verschiedensten>> Geräten, von der Grafikkarte zum Drucker, zum Plotter und wahrscheinlich>> auch auf dem Faxgerät ausgeben zu können.>> ...>> Was ich nämlich nie verstanden habe ist der Punkt, warum der Drucker die>> nicht dokumentenrelevanten Sachen eines Desktops ausdrucken können>> sollte.>> Also die Fenster, die Buttons und sonstige GUI Elemente?>> Kann es sein, dass deine Frage auf einem Missverständnis beruht? Hat> denn das GDI irgendetwas mit GUI-Elementen zu tun?>> Ich bin genauso wenig Windows-Experte wie du, aber m.W. werden> GUI-Elemente auf einer höheren Ebene genauso wie jede andere Grafik aus> Linien, Rechtecken, Bitmaps und dergleichen zusammengesetzt, indem die> entsprechenden GDI-Zeichenfunktionen aufgerufen werden.
Die GUI wird mittels GDI gezeichnet.
Der Punkt ist aber ein anderer, nehmen wir mal an, wir wollen ein
schwarzes Vollmodebild zeichnen und darin drei weiße gleichschenklige
Dreiecke mit einer Kantenlänge von sagen wir mal 16 Pixel in der
horizontalen beliebig verteilt unterbringen.
Wenn man die Grafikkarte direkt nutzen darf, dann kann man das
folgendermaßen machen.
1. Der Framebuffer des Video-RAM der Grafikkarte wird in zwei Bereiche
unterteilt. Die Grafikkarte kann in diesem Modi schnell zwischen diesen
beiden hin und herschalten. Das verhindert Flickering oder der Anwender
bekommt nicht zu sehen, wie ein Bild aufgebaut wird, da das im
Hintergrund in dem Speicherbereich passiert, der gerade nicht im
Vordergrund ist.
2. Dann füllt man diesen Speicherbereich der im Hintergrund ist komplett
mit schwarzer Farbe. Die CPU muss dazu im Prinzip nur einmal diesen
Speicherbereich wie ein Array durchfahren und mit schwarzer Farbe
füllen, also den Wert für die schwarze Farbe da reinschreiben. Das geht
auch in Software sehr schnell und wenn die API Schnittstelle noch
Beschleunigerfeatures unterstützten sollte, dann kann das eine
Grafikkarte mit Beschleunigerfeatures sogar direkt ausführen.
2. Im nächsten Schritt schreibt man in einen weiteren unsichtbaren
Speicherbereich ein Array, das ein kleines Viereck mit der Kantenlänge
16 Pixel, ungefähr von der Größe eines Icons definiert. Dieses Viereck
macht man schwarz und dann zeichnet man darin ein weißes Dreieck.
3. So, jetzt hat man im Speicher ein kleines Viereck mit Dreieck und
jetzt muss man das nur noch in den Speicherbereich des Framebuffers, der
noch im Hintergrund ist kopieren oder ber BitBlit, sofern es die
Grafikkarte unterstützt. Damit das Bild fertig gezeichnet, jetzt muss
man nur noch diesen Framebuffer in den Vordergrund schalten und schon
sieht der Nutzer das schwarze Vollbild mit den drei weißen Dreiecken.
Das funktioniert, weil das eine Grafikkarte ist.
Mit einem Drucker funktioniert das nicht. Denn bei einem Drucker kann
man nicht erst das Papier komplett schwarz bedrucken und dann
anschließen darin wieder drei Dreiecke weiß machen. Beim Drucker muss
man also ganz anders vorgehen und da wo bspw. ein Dreieck beginnt, dann
mit dem Draufspritzen der Tinte aufhören und dann an der anderen Seite,
also wenn man das Bild von rechts nach Links Zeile für Zeile gedruckt
wird, mit der schwarzen Farbe weitermachen.
Da GDI nun aber auch für Drucker geeignet sein muss, muss das ganze Bild
irgendwo im RAM vorher erstellt werden, bevor man es fertig an den
Grafikkartentreiber oder den Druckertreiber schickt.
Man hat also viel mehr Overhead und eine langsamere Grafikausgabe, als
es hätte sein müssen, wenn man für den Drucker eine separate API
geschaffen hätte.
Nano schrieb:> 1.
[...]
DoubleBuffering kann natürlich auch das GDI. Es gibt Bitmaps, es gibt
Blitting.
In hoheren Abstraktionen (z.B. .net Windows.Forms) muß man den Kram dann
nichtmal mehr selber verwalten, sondern einfach nur aktivieren.
Ja klar, das ist wesentlich langsamer als DirectX, aber immerhin
weiterhin geräteunabhängig. Sprich: selbst von so einem
DoubleBuffering-Krams kann man problemlos einen Screenshot in
Druckerauflösung machen.
Nano schrieb:> Mit einem Drucker funktioniert das nicht. Denn bei einem Drucker kann> man nicht erst das Papier komplett schwarz bedrucken und dann> anschließen darin wieder drei Dreiecke weiß machen.
Das geschieht ja auch nicht. Bei Rastergeräten wie bspw. Laserdruckern
wird der Ausdruck erst in einem Bitmappuffer erzeugt und erst dann der
Inhalt dieses Puffers zu Papier gebracht.
Bei dummen Druckern, zu denen auch die so genannten GDI-Drucker gehören,
wird die Bitmap – bspw. so, wie du es beschrieben hast – erst im PC
vollständig aufgebaut und dann Stück für Stück zum Drucker geschaufelt.
Bei einem "intelligenten" Drucker, wie bspw. einem Postscript-Drucker
sieht das ganz ähnlich aus, nur dass dort die Bitmap im Drucker selbst
aufgebaut wird, bevor sie gedruckt wird. Deswegen kann auch auf einem
Postscript-Drucker eine schwarze Fläche mit weißen Objekten "übermalt"
werden.
Nur bei Stiftplottern funktioniert dieses Verfahren nicht, weil sie
keine Rastergeräte sind und deswegen auch keine Bitmap erzeugt wird,
weder im Plotter noch im Treiber auf PC-Seite. Aber für Stiftplotter
wurde GDI wohl auch nicht gemacht.
> Da GDI nun aber auch für Drucker geeignet sein muss, muss das ganze Bild> irgendwo im RAM vorher erstellt werden, bevor man es fertig an den> Grafikkartentreiber oder den Druckertreiber schickt.
Das stimmt nicht. GDI kann auch direkt ins Videomemory rendern - ist
nur eine Frage des Treibers. Ebenso wird auch bei der Druckerausgabe
nicht zwingend eine RAM-Image erstellt - bei Postscript-Druckern z.B.
werden die GDI-Calls soweit möglich direkt in PS-Kommandos umgesetzt.
GDI bietet den Treibern einen Fallback, in einen Off-Screen-Buffer zu
rendern und den dann zu benutzen. Popeltreiber haben das gerne benutzt
- war halt lahmarschig. Die GDI-Drucker haben das auf die Spitze
getrieben: eine Druckkopfzeile rendern lassen und synchron zum Drucker
schicken - dann kann man selbst mit nen paar MB RAM billig 600dpi-Druck
machen.
Das Problem mit Spielen damals war, dass die die gesamte Performance des
Rechners (inkl Grafikkarte) brauchten, um mit den Consolen mithalten zu
können. Ein paar GDI-Calls selbst waren denen schon zuviel - die
wollten direkten, exklusiven Zugriff aufs Video-RAM um dann darin ihre
Tricksereien umzusetzten. DirectDraw & Co lieferte das dann. Mit
Aufkommen von 3D ging das dann wieder zurück - komplexe, HW-unabhänge
API.
Die Sache ist, dass solch eine Spiele-Grafik-API Desktop-Anwendungen
nichts bringt. Die wollen nicht einzelne Pixel bearbeiten, die wollen
eine API, die ihnen die lästigen Details abnimmt, HW-unabhängig ist, die
Nutzung des Bildschirms/der Geräte von mehreren gleichzeitigen
Anwendungen koordiniert, etc. Und dafür war GDI nicht verkehrt. Spiele
waren Anfangs halt nicht die Priorität - haben dann ja nachgeliefert.
.oO(... dass ich mal Microsoft verteidige ...)
Yalu X. schrieb:> Aber für Stiftplotter> wurde GDI wohl auch nicht gemacht.
Stimmt nicht! Die GDI-Funktionen für das Zeichnen von Kurven/Linien
funktionieren gleichermassen auf dem Bildschirm wie auf einem Plotter.
Das war alles schon ziemlich gut durchdacht. Soll ich mal ein altes
Codebeispiel rauskramen?
Andreas S. schrieb:> Yalu X. schrieb:>> Aber für Stiftplotter>> wurde GDI wohl auch nicht gemacht.>> Stimmt nicht! Die GDI-Funktionen für das Zeichnen von Kurven/Linien> funktionieren gleichermassen auf dem Bildschirm wie auf einem Plotter.
Das schon, aber ich nehme an, dass für Plotter nur ein Subset der
GDI-Funktionen unterstützt werden. Oder ist es tatsächlich so, dass eine
beliebige Sequenz von Funktionsaufrufen (siehe Beispiel von Nano vom
06.05.2022 21:06), einmal auf den Bildschirm und einmal auf den Plotter
angewandt, beide Mal mit nur marginalen Einschränkungen (bspw. beim
Farbraum) zum gleichen Ergebnis führen?
Ich frage mich bspw., wie für einen Plotter all die GDI-Funktionen, die
mit Bitmaps zu tun haben, implementiert werden könnten. Werden Bitmaps
etwa als Raster von ganz vielen Punkten umgesetzt? Das wäre dann ja eine
regelrechte Tortur für den Plotter und die Stifte ;-)
Wenn ich Nano richtig verstanden habe, ging seine Kritik ja genau dahin,
dass das GDI nicht nur für den Bildschirm verwendet wird, sondern auch
für Ausgabegeräte, die nur einen Bruchteil der Fähigkeiten haben.
Yalu X. schrieb:> Das schon, aber ich nehme an, dass für Plotter nur ein Subset der> GDI-Funktionen unterstützt werden.
Ganz genau! Bitmaps gehen natürlich nicht, aber alles, was sinnvoll auf
einem Plotter gemacht werden kann, funktioniert. Dazu gehören nicht nur
Linien/Kurven, sondern auch gefüllte Formen ("shapes"). CAD-Programme,
die das GDI verwenden, können den Bildschirminhalt ohne Mehraufwand
direkt auf einen Plotter ausgeben. Vor 25 Jahren war das eine nützliche
Funktion.
Andreas S. schrieb:> Ganz genau! Bitmaps gehen natürlich nicht, aber alles, was sinnvoll auf> einem Plotter gemacht werden kann, funktioniert.
Der ultimative Witz ist: es geht sogar das scheinbar Unmögliche. Sogar
die Ausgabe einer Bitmap auf einen Plotter funktioniert (im Rahmen der
Möglichkeiten des Plotters). Das wird umgesetzt in eine gefühlt endlose
Folge von Line-Anweisungen (mit wechselndem Pen-Parameter).
Allerdings gibt es bei vielen Plottertreibern die Möglichkeit, genau
dies zu unterdrücken. Bei manchen ist die Unterdrückung sogar das
Standardverhalten.
c-hater schrieb:> Der ultimative Witz ist: es geht sogar das scheinbar Unmögliche. Sogar> die Ausgabe einer Bitmap auf einen Plotter funktioniert (im Rahmen der> Möglichkeiten des Plotters).
Natürlich geht das mit Raster.
Kann aber lange dauern.
Auch auf einen Nadeldrucker kann man ein Bildschirmbild ausgeben.
Nano schrieb:> Aber dennoch stellt sich die Frage, warum GDI gleichzeitig Grafikkarten> UND Drucker bedienen können musste.
Du kommst immer mal wieder mit derartigen Fragen, die du dir selbst
hättest beantworten können, wenn du nur ein bissel nachgedacht hättest.
Also ne Gegenfrage:
Warum sollte man 2 Renderer benutzen wollen (einer im PC für den
Monitor, der andere im Drucker), wenn beide letztlich das Gleiche machen
sollen? Oder warum sollte man (historisch gesehen) für 2
Postscript-Renderer Lizenzgebühren abdrücken, wenn man es auch mit nur
einem machen kann?
Denk mal nach...
W.S.
michael_ schrieb:> Bist du aus einem schlimmen Traum erwacht?> Warum, Warum, ...> Fragen machen dumm!https://www.youtube.com/watch?v=uPHi5xn_q5c
Frage beantwortet?
Unabhängig davon hatte ich Fragen zum Makefile gestellt und bin nicht
klüger geworden!
W.S. schrieb:> Nano schrieb:>> Aber dennoch stellt sich die Frage, warum GDI gleichzeitig Grafikkarten>> UND Drucker bedienen können musste.>> Du kommst immer mal wieder mit derartigen Fragen, die du dir selbst> hättest beantworten können, wenn du nur ein bissel nachgedacht hättest.
Die Frage des Warum wurde noch nicht beantwortet. Das es geht, ist
offensichtlich, das es für Microsoft weniger Arbeit gemacht hat sich um
nur eine API zu kümmern wohl auch, aber warum man die Geschwindigkeit
der Grafikausgabe dafür geopfert hat nur um etwas zu können, was man in
den seltensten Fällen auf dem Drucker braucht, ist noch nicht geklärt.
Und dann ist das ja etwas, was man mit Hilfsmitteln auch anders
realisieren hätte können und in der Praxis auch so gemacht wird.
Denn die meisten, die bspw. eine begilderte Konfigurationsanleitung für
Windows erstellen wollen, erstellen Screenshots von den Setupfenstern
mit der Auflösung in dem die Grafikkarte das Fenster auf den Bildschirm
zeichnet um sie dann in ihrem HTML oder Officedokument einzufügen und
dann auszudrucken.
Die Vorteile von GDI, die Oberfläche möglichst in hoher pixelfreier
Auflösung direkt zu drucken wird da somit nicht einmal benutzt. Insofern
stellt sich auch die Frage, in welchen Anwendungsfällen das notwendig
sein sollte, wenn es eh kaum benutzt wird.
Es stellt sich hier zudem auch die Frage, ob Windows Bordmittel hat, um
ein beliebiges Konfigurationsfenster eines WinAPI Programms als GDI
fähiges Objekt (ist das die Aufgabe von OLE Objekten? Frage, da ich kein
großer MS Officenutzer bin) an ein Officedokument weiterzuleiten, so
dass man es wirklich auch pixelfrei in einer hohen Auflösung auf dem
Drucker ausdrucken kann und nicht nur einfach einen niedrig aufgelösten
Screenshot nehmen muss.
> Also ne Gegenfrage:> Warum sollte man 2 Renderer benutzen wollen (einer im PC für den> Monitor, der andere im Drucker), wenn beide letztlich das Gleiche machen> sollen? Oder warum sollte man (historisch gesehen) für 2> Postscript-Renderer Lizenzgebühren abdrücken, wenn man es auch mit nur> einem machen kann?
Das habe ich dir bereits in
Beitrag "Re: GDI von Windows, warum musste ein Drucker Fenster drucken können?"
beantwortet.
Und auf dem Druckerpart muss das ja nicht zwingend ein PS Renderer sein.
MS hätte sich da auch etwas eigenes ausdenken und ebenso lizenzfrei
vergeben bzw. nutzen lassen können.
c-hater schrieb:> Nano schrieb:>>> 1.> [...]>> DoubleBuffering kann natürlich auch das GDI. Es gibt Bitmaps, es gibt> Blitting.
Wenn ich das richtig verstanden habe, dann ist eine auszugebende GDI
"Fläche" eine Ansammlung von Objekten, bestehend aus Grafikprimitiven
wie Linien, Kreise, Punkte, vielleicht aber auch komplexere Objekte wie
Rahmen mit und ohne innere Fläche usw. sowie Pixeldaten für Fälle, die
nicht anders vorliegen, z.B. aus Bilddaten eines eingescannten Fotos.
Im Prinzip also so ne Art Objektverwaltung wie bei einem
Vektorzeichenprogramm (z.B. vergleichbar wie bei dem Vektorprogramm
Inkscape).
Und diese ganzen Objekte werden dann, wie bei Vektorprogrammen auch, in
der Z-Ebene hierarchisch geordnet an die Drucker oder
Grafikschnittstelle gesendet, wo dann erst auf die gerätespezifischen
Eigenheiten eingegangen wird. Was davon noch genereller
gerätespezifischer API Teil, aber noch nicht Treiberspezifisch sein kann
und was davon im spezifischen Gerätetreiber des Herstellers stecken
muss, wäre noch die andere Frage.
Bei Windows 3.x soll es sehr aufwändig sein, einen Grafiktreiber zu
erstellen, weswegen es für Windows 3.x keine VESA Treiber gibt.
Daher dürfte dort noch viel des GDI Zeugs im konkreten
Grafikkartentreiber stecken.
Erst in Win95 und den späteren WinNT Betriebssystemen soll dieser
Aufwand wieder geringer gewesen sein, zumindest vor der Zeit der Ausgabe
über die 3d Schnittstellen.
Also in etwa so:
1
GDI
2
|
3
|- Drucker API (gerätespezifischer API Teil)
4
| |
5
| |- Drucker XY von Hersteller A
6
| |- Drucker XY+1 von Hersteller A
7
| |- Drucker Z von Hersteller B
8
| |- Drucker Z++ von Hersteller B
9
| usw.
10
|
11
|- Grafik API (gerätespezifischer API Teil)
12
| |
13
| |- Grafikkarte Y von Hersteller M
14
| |- Grafikkarte Y++ von Hersteller M
15
| |- Grafikkarte I von Hersteller B
16
| |- Grafikkarte I++ von Hersteller B
17
| usw.
18
|
19
usw. (sonstige Geräte, wie Plotter)
So stelle ich mir das vor, denn wie sonst könnte man dann ein obiges
Beispielbild mit dem schwarzen Hintergrund und den drei weißen Dreiecken
noch gerätespezifisch optimieren, wenn die Primitive nicht mehr in ihrer
Grundform vorliegen.
Den Aufwand der Objekteverwaltung hat man also aber definitiv und das
geht auf die Kosten der Grafikperformance, wenn man GDI für die
Grafikausgabe verwendet.
Und natürlich kann man mit 2d Beschleunigerkarten die Ausgabe solcher
Vektorobjekte dann wieder beschleunigen, aber auf einen "dummen
Grafikkarte" ist das natürlich nicht der Fall, da wäre die Ausgabe ohne
den Objekteoverhread performanter.
Wenn dem nicht so sein sollte, dann könnt ihr mich hier gerne
korrigieren.
Nano schrieb:> warum man die Geschwindigkeit> der Grafikausgabe dafür geopfert hat nur um etwas zu können, was man in> den seltensten Fällen auf dem Drucker braucht, ist noch nicht geklärt.
Begreifst Du es wirklich nicht, oder willst Du bloss diskutieren?
Windows wurde nicht für den zockenden Nano entwickelt, sondern in erster
Linie für Büroanwendungen. Und was macht man als typischer Büroanwender
mit einem Computer?
Man schreibt Dokumente - und druckt sie aus.
Man erstellt Spreadsheets, macht daraus tolle Diagramme - und druckt sie
aus.
Und wenn Du in Deinem Leben mal die eine oder andere Zeile Code
geschrieben hättest, dann wüsstest Du, dass GDI für sowas sehr gut
funktioniert, weil es für den Code weitestgehend egal ist, ob er in
einem Fenster oder auf einem Blatt Papier malt.
Dass die GUI über GDI nur auf dem Bildschirm malt, ist dabei völlig
irrelevant, denn GDI ist vorhanden, so dass man das Rad nicht doppelt
erfinden musste. Das Interesse an Vektor-Screenshots hielt sich wohl
eher in Grenzen.
Soweit ich weiss, nutzt RDP übrigens GDI, um nicht alle
Bildschirmänderungen als Bitmaps übertragen zu müssen.
Nano schrieb:> Und auf dem Druckerpart muss das ja nicht zwingend ein PS Renderer sein.> MS hätte sich da auch etwas eigenes ausdenken und ebenso lizenzfrei> vergeben bzw. nutzen lassen können.
Status quo: Die Anwendung ruft GDI-Zeichenfunktionen auf, um Grafiken
darzustellen, egal auf welchem Ausgabegerät.
Nanos Weisheit: Die Anwendung erzeugt ein PostScript-Derivat, das
Windows erst parsen und dann ebenfalls an Zeichenfunktionen verfüttern
muss.
Was glaubst Du, welcher der beiden Wege effizienter ist?
foobar schrieb:>> Da GDI nun aber auch für Drucker geeignet sein muss, muss das ganze Bild>> irgendwo im RAM vorher erstellt werden, bevor man es fertig an den>> Grafikkartentreiber oder den Druckertreiber schickt.>> Das stimmt nicht. GDI kann auch direkt ins Videomemory rendern - ist> nur eine Frage des Treibers.
Der Objekteoverhead hat man, um den wird man nicht herum kommen. Siehe
mein vorheriges Posting.
Wenn GDI Geräteunabhängig sein soll, dann werden diese Grafikprimitive
bzw. Objekte direkt so an die Gerätespezifischen APIs oder gleich
Treiber gesendet werden müssen, ansonsten könnte man das nicht mehr
anschließend geräteunabhängig optimieren.
> Ebenso wird auch bei der Druckerausgabe> nicht zwingend eine RAM-Image erstellt - bei Postscript-Druckern z.B.> werden die GDI-Calls soweit möglich direkt in PS-Kommandos umgesetzt.
Ja, das war jetzt natürlich eine Möglichkeit. Dass PS Kommandos Sinn
machen können, wenn der Drucker PS kann, ist ja klar.
> GDI bietet den Treibern einen Fallback, in einen Off-Screen-Buffer zu> rendern und den dann zu benutzen.
Das ist gut zu wissen. Aber warum gibt es dann keine VESA Treiber für
Windows 3.x in extremlahm?
Es gibt ja schon keine lahmen VESA Treiber mit viel Treiberaufwand, also
solche VESA Treiber die speziell mit GDI umgehen können.
> Popeltreiber haben das gerne benutzt> - war halt lahmarschig. Die GDI-Drucker haben das auf die Spitze> getrieben: eine Druckkopfzeile rendern lassen und synchron zum Drucker> schicken - dann kann man selbst mit nen paar MB RAM billig 600dpi-Druck> machen.
Damals war RAM noch teuer und CPU Leistung auch.
Es ist verständlich, dass da die billigen Drucker damals die ganze
Arbeit noch den PC machen ließen.
> Das Problem mit Spielen damals war, dass die die gesamte Performance des> Rechners (inkl Grafikkarte) brauchten, um mit den Consolen mithalten zu> können. Ein paar GDI-Calls selbst waren denen schon zuviel - die> wollten direkten, exklusiven Zugriff aufs Video-RAM um dann darin ihre> Tricksereien umzusetzten. DirectDraw & Co lieferte das dann. Mit> Aufkommen von 3D ging das dann wieder zurück - komplexe, HW-unabhänge> API.
Ja.
> Die Sache ist, dass solch eine Spiele-Grafik-API Desktop-Anwendungen> nichts bringt. Die wollen nicht einzelne Pixel bearbeiten, die wollen> eine API, die ihnen die lästigen Details abnimmt, HW-unabhängig ist, die> Nutzung des Bildschirms/der Geräte von mehreren gleichzeitigen> Anwendungen koordiniert, etc. Und dafür war GDI nicht verkehrt.
Das ist schon klar und bestreite ich auch nicht.
Aber GDI war ja mehr als nur eine geräteunabhänige Grafikkartenausgabe,
es war bzw ist eine universelle API für alle möglichen Ausgabeformen.
Man hätte so eine API, die dem Office Anwendungsentwickler die lästigen
Details abnimmt, Grafikkartenhardwareunabhängig ist, die Nutzung des
Bildschirms/Computers von mehreren gleichzeitigen Anwendungen
kooridiniert erlaubt ja auch einfach als API lösen können, die nur für
Grafikkarten entwickelt wurde.
Und wer dann seine Dokumente drucken will, der schickt diese an eine auf
Drucker optimierte Dokumentenapi, wovon PS eine davon ist, aber MS hätte
da auch etwas eigenes bauen können, das dann auch die ganze Arbeit auf
dem PC macht und so billige Drucker erlaubt.
Yalu X. schrieb:> Wenn ich Nano richtig verstanden habe, ging seine Kritik ja genau dahin,> dass das GDI nicht nur für den Bildschirm verwendet wird, sondern auch> für Ausgabegeräte, die nur einen Bruchteil der Fähigkeiten haben.
Ja, so in etwa.
Wobei mir es da eher um die Optimierung geht.
Wenn man beliebige Gerätearten unterstützen will, dann wird das
unweigerlich
einen so hohen Abstraktionsgraf aufweisen müssen, dass es nicht die
performanteste Lösung ist.
Und das ist eigentlich mein Punkt.
Reißerisch, wie in meinem Titel also formuliert, kann man sagen, man hat
die Performance bei der Grafikkartenausgabe geopfert, damit der Drucker
auch die GUIs, die man auf dem Bildschirm sieht, ausdrucken kann.
Und heute machen die Endanwender alle Screenshots von ihren
Anwendungenm, die sie in ihr Office Dokument einbetten, anstatt GDI
Objekte, die zu einem viel schöneren Druck führen würden. ;)
Korrektur.
Der Bezeichner "Drucker" sollte in der Grafik natürlich für den
Druckertreiber für den spezifischen Drucker
und
"Grafikkarte" für den Grafikkartentreiber für die spezifische
Grafikkarte
stehen.
Da ging es mir also um die Treiber.
Nano schrieb:> Wenn man beliebige Gerätearten unterstützen will, dann wird das> unweigerlich> einen so hohen Abstraktionsgraf aufweisen müssen, dass es nicht die> performanteste Lösung ist.
Das war bei der tatsächlichen Nutzung deutlich weniger relevant als
WYSIWYG. Je mehr Code für alle Ausgabevarianten verwendet wird, desto
grösser ist die Wahrscheinlichkeit, dass das Gedruckte auch dem
entspricht, was man vorher auf dem Bildschirm gesehen hat.
Falls Du in den 90ern noch mit einer Rassel um den Tannenbaum gerannt
sein solltest: Als Windows noch ein reiner DOS-Aufsatz war, liefen
darunter fast nur Anwendungen, während Spiele weiterhin nacktes DOS
wollten.
Auch DirectX wurde zuerst nicht so recht angenommen, weshalb Microsoft
1996 für id Software kostenlos Doom auf DirectX portiert hat.
Hmmm schrieb:> Nano schrieb:>> warum man die Geschwindigkeit>> der Grafikausgabe dafür geopfert hat nur um etwas zu können, was man in>> den seltensten Fällen auf dem Drucker braucht, ist noch nicht geklärt.>> Begreifst Du es wirklich nicht, oder willst Du bloss diskutieren?>> Windows wurde nicht für den zockenden Nano entwickelt, sondern in erster> Linie für Büroanwendungen. Und was macht man als typischer Büroanwender> mit einem Computer?
Auch der Büroanwender will eine performante Ausgabe seiner
Officedokumente.
Deswegen hat der viel Geld für damals teure Windows 2d
Beschleunigerkarten ausgegeben und die Industrie hat die Nachfrage mit
solchen 2d Beschleunigerkarten bedient.
Diese 2d Fensterbeschleunigerfeatures konnten die Gamer übrigens lange
Zeit nicht nutzen.
> Man schreibt Dokumente - und druckt sie aus.> Man erstellt Spreadsheets, macht daraus tolle Diagramme - und druckt sie> aus.
Und er will durch das Dokument dabei trotzdem schnell und ruckelfrei
scrollen können!
Bestimmt bist du der erste, der sich beschwert, wenn es ewig dauert,
wenn du in einem 600 Seiten PDF Katalog blättern musst und die Anzeige
nicht schnell und performant flutscht.
Eine performante Grafikkausgabe ist also keineswegs nur eine Domäne der
Spiele, sondern auch im Officebereich wichtig.
Mit heutiger Hardware merkst du davon vielleicht nicht mehr viel, aber
früher war das noch mehr als deutlich, wenn der Bildaufbau langsam war.
In dem Vektorzeichenprogramm CorelDraw konnte man bei komplexeren
Grafiken dem Computer noch zugucken, wie er langsam das Bild aufgebaut
hat und es konnte damals den Leuten nicht schnell genug gehen.
Adobe ist bei Photoshop 3 und 4 sogar zur WinG Schnittstelle umgestiegen
sobald sie verfügbar war, weil ihnen GDI zu langsam war.
https://en.wikipedia.org/wiki/WinG#List_of_applications_using_WinG_API> Und wenn Du in Deinem Leben mal die eine oder andere Zeile Code> geschrieben hättest, dann wüsstest Du, dass GDI für sowas sehr gut> funktioniert, weil es für den Code weitestgehend egal ist, ob er in> einem Fenster oder auf einem Blatt Papier malt.
Und wenn du programmieren könntest oder etwas von Informatik verstehen
würdest, dann würdest du kapieren, warum ich diese Fragen hier stelle
und das nicht alles einfach als MS gegeben hinnehme.
> Nano schrieb:>> Und auf dem Druckerpart muss das ja nicht zwingend ein PS Renderer sein.>> MS hätte sich da auch etwas eigenes ausdenken und ebenso lizenzfrei>> vergeben bzw. nutzen lassen können.>> Status quo: Die Anwendung ruft GDI-Zeichenfunktionen auf, um Grafiken> darzustellen, egal auf welchem Ausgabegerät.>> Nanos Weisheit: Die Anwendung erzeugt ein PostScript-Derivat, das> Windows erst parsen und dann ebenfalls an Zeichenfunktionen verfüttern> muss.>> Was glaubst Du, welcher der beiden Wege effizienter ist?
Da der zweite Weg die Grafikausgabe nicht unnötig ausbremst, ist der
natürlich effizienter, wenn einem eine performante Grafikausgabe wichtig
ist.
Aber du hast schon durchblicken lassen, dass du nicht wirklich verstehst
wie das unter der Haube funktioniert und deswegen ist das für dich
einerlei und egal, aber in der Praxis war es eben nie egal. Siehe oben,
was ich da geschrieben habe.
Und das die Entwicklung einer zweiten API für MS ökonomischer, im Bezug
auf das Finanzielle, sei, habe ich auch nie behauptet. Ich sagte sogar
oben das Gegenteil, aber dafür kriegt man dann auch etwas zurück,
nämlich eine performantere Grafikausgabe die früher halt auch im
Officebereich noch relevant war. Siehe die obigen Beispiele.
Deine persönlichen Angriffe sind allerdings gehörig deplaziert.
Hmmm schrieb:> Nano schrieb:>> Wenn man beliebige Gerätearten unterstützen will, dann wird das>> unweigerlich>> einen so hohen Abstraktionsgraf aufweisen müssen, dass es nicht die>> performanteste Lösung ist.>> Das war bei der tatsächlichen Nutzung deutlich weniger relevant als> WYSIWYG.
Mit WYSIWYG war aber nicht gemeint, dass man eine universelle API hat.
Das ist natürlich ein netter Nebeneffekt von GDI, dass das dann ohne
viel Mehraufwand dabei ist.
Bei WYSISYG ging es um etwas anderes. Nämlich das eine Schrift eine
beliebige Form annehmen kann und dann auch auf dem Bildschirm, so wie
auf dem Ausdruck vom Drucker aussieht und nicht mehr nur so ein
Textschrift mit fester breite ist, wie man sie noch in DOS Editoren
üblicherweise hatte.
Das hätte man natürlich auch mit zwei getrennten APIs, eine für
Grafikkarten, eine für Drucker, ganz genauso hinkriegen können.
> Je mehr Code für alle Ausgabevarianten verwendet wird, desto> grösser ist die Wahrscheinlichkeit, dass das Gedruckte auch dem> entspricht, was man vorher auf dem Bildschirm gesehen hat.
Das mag sein. Aber daraus kann man nicht schließen, dass es bspw. eine
gute Idee wäre, Phostscript auch für Grafikkarten zu nutzen.
> Falls Du in den 90ern noch mit einer Rassel um den Tannenbaum gerannt> sein solltest: Als Windows noch ein reiner DOS-Aufsatz war, liefen> darunter fast nur Anwendungen, während Spiele weiterhin nacktes DOS> wollten.
Und das wegen GDI.
Erst WinG verschaffte Abhilfe.
> Auch DirectX wurde zuerst nicht so recht angenommen, weshalb Microsoft> 1996 für id Software kostenlos Doom auf DirectX portiert hat.
Als Windows 95 auf den Markt kam, waren sich viele noch nicht einmal
sicher, ob jetzt IBM mit OS/2 das OS Rennen verloren hat. Außerdem
braucht die Entwicklung auch Zeit, man stellt nicht vom einen auf den
anderen Tag eine Spieleentwicklung auf ein anderes OS um.
Angenommen wurde es für neue Entwicklungen allerdings durchaus.
Und als Win96 raus kam, war DOS zu dem Zeitpunkt überall verfügbar und
mit den DOS Extendern und den VESA Modi waren die zwei größten
Problempunkte unter DOS gelöst.
Erstere erlaubten 32 Bit Protected Mode Spiele mit großem linearen
Adressbereich und somit viel RAM ohne Verrenkungen und zweiteres hohe
Auflösungen mit vielen Farben.
Und das Microsoft für Windows 95 gehörig die Werbetrommel rührt war
klar.
Der Übergang der Spieleentwicklung von DOS zu Windows war also fließend
und ging immer schneller. Schon 2-3 Jahre später, die typische
Entwicklungszeit eines AAA Spieles, gab's praktisch kaum noch neue AAA
Spiele für DOS.
Nano schrieb:> Deswegen hat der viel Geld für damals teure Windows 2d> Beschleunigerkarten ausgegeben und die Industrie hat die Nachfrage mit> solchen 2d Beschleunigerkarten bedient.
...die man dank GDI problemlos einbinden konnte, was bei einem (bei
reinen Framebuffern sehr effizienten) direkten Zugriff auf die
Grafikkarte schiefgegangen wäre.
Nano schrieb:> Und wenn du programmieren könntestNano schrieb:> dann würdest du kapieren, warum ich diese Fragen hier stelleNano schrieb:> Aber du hast schon durchblicken lassen, dass du nicht wirklich verstehst> wie das unter der Haube funktioniert
Immer dasselbe Schema in Deinen Threads: Eine doofe Frage, ein paar
fundierte Antworten, und dann packst Du aus, was Du alles viel besser
gemacht hättest.
Man erlebt selten Menschen, die trotz immer wieder zur Schau gestellter
Inkompetenz so arrogant sind wie Du.
Nano schrieb:> Es ist nun einmal Fakt, dass man bei der Zahl PI daran forscht, wie viel> Stellen nach dem Komma diese Zahl hat, auch wenn du mit deinem> Flacherdlerglauben da deine Probeleme hast.
Das ist Unsinn, Chuck Norris hat Pi inzwischen vollständig diktiert.
Reinhard S. schrieb:> (prx) A. K. schrieb:>>> Während eine Kalbsleberwurst Kalbfleisch enthält, schlachtet man>> für eine Bauernleberwurst keine Bauern.>> Das wollen SIE uns weismachen...
Fas verwechselst Du mit Zigeunerschnitzeln und Mohrenköpfen. Bei
Amerikanern und Hanseaten gibt es auch üble Gerüchte.
Hmmm schrieb:> Nano schrieb:>> Deswegen hat der viel Geld für damals teure Windows 2d>> Beschleunigerkarten ausgegeben und die Industrie hat die Nachfrage mit>> solchen 2d Beschleunigerkarten bedient.>> ...die man dank GDI problemlos einbinden konnte, was bei einem (bei> reinen Framebuffern sehr effizienten) direkten Zugriff auf die> Grafikkarte schiefgegangen wäre.
Von einem reinen Framebuffer war aber nicht die Rede, sondern einer
Grafik API die auf Grafikkarten optimiert ist. Denn die Anwendungen
rufen die Grafikroutinen dieser API von Windows dann auf und diese setzt
das dann um bzw. leitet es an die Treiber weiter.
Das ist übrigens auch bei WinG und DirectDraw so.
D.h. hier kann man seitens Microsoft so abstrahieren, dass die
Treiberhersteller das für die Grafikkarte in den Treibern dann
optimieren und die Beschleunigerfunktionen dann nutzen können.
Hmmm schrieb:> Nano schrieb:>> Und wenn du programmieren könntest>> Immer dasselbe Schema in Deinen Threads: Eine doofe Frage, ein paar> fundierte Antworten, und dann packst Du aus, was Du alles viel besser> gemacht hättest.>> Man erlebt selten Menschen, die trotz immer wieder zur Schau gestellter> Inkompetenz so arrogant sind wie Du.
Du jammerst wie ein Lappen. Denn du willst austeilen und bestimmst sogar
mit deiner Art und Weise, wie du eine Diskussion beginnst, wie die
Diskussion geführt werden soll, siehe:
Hmmm schrieb:> Begreifst Du es wirklich nicht, oder willst Du bloss diskutieren?>> Windows wurde nicht für den zockenden Nano entwickelt,...Hmmm schrieb:> Und wenn Du in Deinem Leben mal die eine oder andere Zeile Code> geschrieben hättest,Hmmm schrieb:> Nanos Weisheit: Die Anwendung erzeugt ein PostScript-Derivat, das> Windows erst parsen und dann ebenfalls an Zeichenfunktionen verfüttern> muss.Hmmm schrieb:> Falls Du in den 90ern noch mit einer Rassel um den Tannenbaum gerannt> sein solltest:
Und dann jammerst du hinterher rum, wenn du genau diese Diskussion dann
kriegst, die DU mit mir schon immer führen wolltest.
Es liegst also nicht an mir, sondern allein an dir. Mit vielen anderen
funktioniert eine normale sachliche Diskussion auf sachlicher Ebene. Du
aber, du willst nicht sachlich diskutieren, sondern auf privater Ebene
persönlich werden und wenn man dir dann die Leviten vorliest und du
deine eigene Diskussionseinstellung vor Augen geführt bekommst, dann
jammerst du rum.
Fundierte Antworten, wie du hier fälschlicherweise vorgibst, hast du
hier übrigens auch nicht geliefert.
Mein letzter Kommentar zu diesen Thread:
Die Prämisse, GDI ist langsam weil es auch Drucker unterstützt ist
einfach Quatsch!
GDI ist für die Erstellung von Desktop-Umgebungen entwickelt, d.h.
mehrere überlappende Fenster von mehreren gleichzeitige Anwendungen.
Hauptaufgabe dabei ist das Verwaltung von Clip-Listen und die
Zerstückelung von Malbefehlen durch die Clip-Listen. Bei Amiga war das
Pendant das Graphics- und Layers-Library, bei Unix X11 (die beiden
Systeme, die ich genauer kenne). Diese Aufgabe hat GDI vergleichbar
schnell wie alle andere erledigt. Ist dummerweise genau das Gegenteil
von dem ist, was Spiele-Programmierer haben wollen (exklusiven Zugriff
auf den gesamten Bildschirm). Beim Amiga gab es HW, die das dann doch
noch erlaubte; bei X11 ist es immer noch duster (läuft meist am X11
vorbei).
Das MS GDI so designed hat, dass es zusätzlich auch für die
Druckerausgabe genutzt werden kann (die API hat gewisse Ähnlichkeit
mit PS), hat der Bildschirmausgabegeschwindigkeit aber nicht geschadet.
Nano schrieb:> Und auf dem Druckerpart muss das ja nicht zwingend ein PS Renderer sein.> MS hätte sich da auch etwas eigenes ausdenken
Geil, NOCH inkompatibler.
Mit dir wäre die Computerbranche schon 20 Jahre früher verreckt.
Damals gab es WYSIWYG, das ist heute ja in Vergessenheit geraten, siehe
das markup Eingabefeld in diesem Forum oder allgemein die
WebSeitenErstellung. Statt Doxygen gab es schon in den 80gern WEB von
Knuth, nein, nicht das was Kinder heute unter dem Web verstehen sondern
ein Dokumentationssystem für Programme dessen Ergebnis druckreif war.
Man ist heute eher wieder bei 1970 angekommen, dank der ganzen
Dorftrottel in der IT.
Macht TeX Knuth also zum Dorftrottel?
Ich hatte mit beidem zu tun, der Sprache eines Satzsystems grob
vergleichbar mit TeX, und dessen und andere WYSIWYG-Interfaces. Mit der
Sprache plus Live-Rendering tat ich mich leichter als mit
ausschliesslichem WYSIWYG-Interface. Diese Erfahrung zieht sich bis zu
den heutigen Markup-Systemen wie Joplin im Vergleich zu den
WYSIWYG-Alternativen.
(prx) A. K. schrieb:> Macht TeX Knuth also zum Dorftrottel?
Knuth war weiter als die meisten seiner Zeit, aber die auf ihn folgrnden
Dorftrottel haben bis heute keinen ordentlichen TeX WYSIWYG Editor
hinbekommen. Ich weiss, es gibt einige Versuche, die hab ich probiert,
keiner taugt.
Nano schrieb:> Wenn man beliebige Gerätearten unterstützen will, dann wird das> unweigerlich> einen so hohen Abstraktionsgraf aufweisen müssen, dass es nicht die> performanteste Lösung ist.
Das ist praktisch unweigerlich so, ja.
> Reißerisch, wie in meinem Titel also formuliert, kann man sagen, man hat> die Performance bei der Grafikkartenausgabe geopfert, damit der Drucker> auch die GUIs, die man auf dem Bildschirm sieht, ausdrucken kann.
Nein, das ist falsch. Richtig ist: Man hat ganz bewußt eine
Infrastruktur geschaffen, die mit allem funktioniert, was irgendwie ein
Bild darstellen kann. Das war primäres Designziel.
> Und heute machen die Endanwender alle Screenshots von ihren> Anwendungenm, die sie in ihr Office Dokument einbetten, anstatt GDI> Objekte, die zu einem viel schöneren Druck führen würden. ;)
Das ist (historisch gesehen) allein die Schuld der Benutzer. Man kann
wunderschön GDI-kompatible Sammlungen von Vektordaten in
Office-Dokumente einbetten. Die entsprechenden Formate heißen WMF/EMF
und man kann sie problemlos systemweit per Zwischenablage transferieren.
Ist nur etwas aus der Mode gekommen, eben wegen der Dummheit der weit
überwiegenden Zahl von Benutzern und (so muss man leider sagen) auch der
inzwischen überwiegenden Zahl von Programmierern. Wenn die den Kram
nicht als WMF in's Clipboard legen, kann's der Benutzer natürlich auch
nicht als WMF woanders einfügen, selbst wenn er weiß, wie das
prinzipiell zu machen wäre...
Hier wurde also ein prinzipiell geiles Konzept über die Jahre allein von
der Dummheit der Benutzer gekillt.
Na gut, Microsoft macht es den Leuten auch nicht wirklich einfach...
c-hater schrieb:>> Und heute machen die Endanwender alle Screenshots von ihren>> Anwendungenm, die sie in ihr Office Dokument einbetten, anstatt GDI>> Objekte, die zu einem viel schöneren Druck führen würden. ;)>> Das ist (historisch gesehen) allein die Schuld der Benutzer.
Nein, das ist die Schuld von Microsoft. Die Benutzer haben nämlich schon
früh gelernt, dass beim Copy-Pasten von Grafiken (bspw. von Excel oder
von Project nach Word) in den allermeisten Fällen nur ein Haufen Salat
in der Zielanwendung ankommt. Der einzig praktikable Workaround war das
Kopieren von Bitmaps. Das ist zwar meist qualitativ minderwertig und
speicherfressend, aber wenigstens war die Grafik am Zielort noch als
solche erkennbar. Was ich diesbezüglich schon an Zeit für erfolglose
Frickeleien geopfert habe ...
Das ist aber nicht nur ein Problem des GDI, sondern vor allem der
Anwendungsprogramme, die das Konzept fehlerhaft umsetzen.
> Ist nur etwas aus der Mode gekommen,
Nein, das war überhaupt noch nie in Mode, weil es noch nie zuverlässig
funktioniert hat.
> eben wegen der Dummheit der weit überwiegenden Zahl von Benutzern
... die eben bei mehreren zur Verfügung stehenden Alternativen
verständlicherweise diejenige auswählen, die wenigstens halbwegs
funktioniert.
> und (so muss man leider sagen) auch der inzwischen überwiegenden Zahl> von Programmierern.
... allen voran derjenigen von Microsoft.
> Na gut, Microsoft macht es den Leuten auch nicht wirklich einfach...
Da bin ich ausnahmsweise mal völlig deiner Meinung :)
Yalu X. schrieb:> Das ist aber nicht nur ein Problem des GDI, sondern vor allem der> Anwendungsprogramme, die das Konzept fehlerhaft umsetzen.
Ganz genau.
> Nein, das war überhaupt noch nie in Mode, weil es noch nie zuverlässig> funktioniert hat.
also innerhalb von z.B. MS-Works3.5 oder 4.0, Word6 und Excel5 hat das
noch perfekt funktioniert. Auch das damalige CorelDraw4 hat immerhin
meistens was Verwendbares produziert.
Das kann ich sagen, weil ich all das selber aktiv benutzt habe.
>> und (so muss man leider sagen) auch der inzwischen überwiegenden Zahl>> von Programmierern.>> ... allen voran derjenigen von Microsoft.
Jepp. die alte Riege, die noch wußte, wie das System eigentlich
funktioniert, ist in Rente. Ich auch bald. Thanks god...
Heute sind die "agilen" Jungspunde am Werk. Nunja, allein die Qualität
der Sicherheitsupdates spricht hier Bände. Ist praktisch vollkommen auf
OSS-Niveau gesunken...
Nur, dass man halt im Unterschied zu OSS immer noch für den Mist zahlen
muss. Mit Geld oder mit Daten. Allerdings ist die Datensammelwut längst
auch in der OSS-Szene angekommen. Eigentlich alles, was auch nur einen
Call über dem Kernel liegt, telefoniert heute mehr oder weniger
hemmungslos "nach Hause".
c-hater schrieb:> Heute sind die "agilen" Jungspunde am Werk. Nunja, allein die Qualität> der Sicherheitsupdates spricht hier Bände. Ist praktisch vollkommen auf> OSS-Niveau gesunken...
Für mich der beste Satz im gesamten Thread. Ich durfte das Ganze noch
richig live erleben, genau so wie Du das hier formuliert hast.
Allerdings muß ich mir das nicht mehr tagtäglich antun, da ich seit
einiger Zeit keinen Wecker mehr stellen muß.
Nano schrieb:> Falsches Thema und komplett auf dem falschen Dampfer!>> Das konnte WinG und DirectDraw (bei Software ohne Karte mit 2d> Beschleunigerfunktionen) auch. Der Unterschied ist aber, dass GDI für> jedes Grafikprimitiv ein Objekt erzeugt und noch einen Haufen Ballast> mitbringt. GDI ist und war eben nie schnell. Für Spiele war es so> langsam, dass es absolut unbrauchbar war, damit etwas sinnvolles> performantes hinzubekommen.
Es scheint hier am historischen Kontext zu fehlen!
DirectDraw kam erst mit DirectX, und das kam 1995, zusammen mit Windows
95.
Wie weiter oben schon steht: das GDI gibt es seit Windows 1.0.
Spiele wurden damals noch hardwarenah programmiert, ohne Windows, die
liefen unter DOS. Unter Gamern hieß es zu Windows damals: gesehen,
gelacht, F8. (Das war ein Shortcut um Windows zu beenden.)
Ich selbst habe mit Windows 3.1 angefangen.
Und das GDI als Druckerinterface war eine Offenbarung!
Vorher, unter DOS, musste man aus dem Programm heraus druckerspezifische
Befehle an den Parallelport schicken. D.h. man schickte die zu
druckenden Buchstaben, angereichert um Steuerkommandos für "fett",
"doppelt breit", "kursiv". Man konnte dann aber nur die Schriftarten
benutzen, die im Drucker eingebaut waren. Und alle waren Monospaced.
Sobald man irgendwas grafisches Drucken wollte musste man den Drucker in
einen Grafikmodus versetzen, selbst Pixeldaten berechnen und
verschicken. Z.B. ein Byte für 8 übereinanderstehende Pixel, dann
bewegte sich der Druckkopf ein Pixel nach rechts und wartete auf die
nächsten 8. Wenn dein Nachbar einen anderen Drucker hatte, mit einem
anderen Befehlssatz, dann konnte dein Programm da gar nicht drucken.
Oder du hast mehrere Drucker-Ansteuerungen programmiert. Am Besten mit
einem weitverbreiteten "kompatiblen" Befehlssatz, dann ging immerhin die
Textausgabe...
Das wurde mit dem GDI von Windows deutlich besser.
Jedes Windows-Programm konnte mit dem GDI umgehen und der Druckertreiber
wusste, wie er das aufs Papier bringt. Ganz gleich ob Epson-9-Nadler
oder HP Laserjet.
Auch für die Grafik war das im Allgemeinen kein Nachteil - zum Zeitpunkt
der GDI-Einführung. Damals waren die meisten Grafikkarten nicht
wesentlich mehr als ein Pixel-Speicher, der auf dem Bildschirm
ausgegeben wurde. Linien oder Schrift wurden in Software gemacht. Die
Windows-Gui hat viele horizontale und senkrechte Linien - die in
Software zu malen ist kein Problem. Auch unter Linux war das
Framebuffer-Device lange Zeit die Standard-Schnittstelle.
Teuer waren damals CAD-Grafikkarten, die z.B. schräge Linien oder Kreise
"selber" malen konnten. Man brauchte dann aber Spezialsoftware, teure
CAD-Programme, die genau darauf ausgerichtet waren, mit deiner
Grafikkarte oder besonderen Graka-Treibern (z.B. dem Heidi-Treiber) zu
sprechen.
Auch das wurde mit dem GDI unter Windows super! Du brauchtest nur einen
Windows-Treiber für deine Graka - alle Windows-Programme funktionierten!
Das gabs vor GDI nicht. Word 4.0 unter Dos lief auf meinem Rechner z.B.
nur schwarz-weiß - weil Word meine Grafikkarte nicht mochte.
Multiplan (das war eine Tabellenkalkulation) nur im Textmodus.
Und die gleiche API für Grafik und Drucker ist in 2D kein Nachteil: Ich
habe 1995 ein kommerzielles Programm geschrieben, das eine Art
Report-Generator enthielt. Mit dem gleichen Programmcode, der die
Bildschirmanzeige machte, konnte ich auch drucken! Das selbe
GDI-Interface, einziger Unterschied: der Drucker hat mehr Pixel. Und
sogar Faxen! Ist ja auch nur ein Drucker, den man per GDI ansteuern
kann.
Ein bischen Hardwarebeschleunigung gabs trotzdem: Wenn z.B. eine
Grafikkarte Kreise zeichnen konnte, konnte der Treiber die
GDI-Kreismalbefehle durchreichen. Wenn nicht, dann halt in Software -
funktioniert hat es immer.
Als DirectX rauskam haben viele das als gewaltigen Rückschritt
empfunden. Die wunderschöne Abstraktionsschicht, die immer funktioniert
hat, mit jeder Hardware, wurde nur für die Spieleperformance
aufgeweicht.
Und mit den Möglichkeiten kam der Bloat. Ich habe bis heute nicht
verstanden, wofür die Startleiste 3D-Unterstützung braucht. Aber ohne
DirectX war irgendwann fast alles lahm.
Tilo R. schrieb:> Ich selbst habe mit Windows 3.1 angefangen.> Und das GDI als Druckerinterface war eine Offenbarung!>...> Wenn dein Nachbar einen anderen Drucker hatte, mit einem> anderen Befehlssatz, dann konnte dein Programm da gar nicht drucken.> ..> Das wurde mit dem GDI von Windows deutlich besser.> Jedes Windows-Programm konnte mit dem GDI umgehen und der Druckertreiber> wusste, wie er das aufs Papier bringt. Ganz gleich ob Epson-9-Nadler> oder HP Laserjet.>> Auch für die Grafik war das im Allgemeinen kein Nachteil - zum Zeitpunkt> der GDI-Einführung.> ...> Auch das wurde mit dem GDI unter Windows super! Du brauchtest nur einen> Windows-Treiber für deine Graka - alle Windows-Programme funktionierten!>> Das gabs vor GDI nicht.
Es ging hier in diesem Thread nie darum dass man eine
Abstraktionsschicht für Drucker und eine Abstraktionsschicht für die
Grafikkarten hat, sondern es geht hier darum, dass die
Abstraktionsschicht sowohl für Drucker, als auch Grafikkarten, als auch
Plotter und sonstiges gleichermaßen geeignet ist.
Es also nur eine ist für alle möglichen Geräte.
Das gleiche ist aber auch mit vielen Abstraktionsschichten für jede
Geräteklasse möglich, die dann auf die jeweilige Geräteklasse optimiert
sind und das ist der Punkt.
Dass eine Abstraktionsschicht es dem Anwendungsprogrammierer erspart,
keine eigenen HW Treiber schreiben zu müssen, ist klar, aber nicht das
Thema hier.
> Und die gleiche API für Grafik und Drucker ist in 2D kein Nachteil: Ich> habe 1995 ein kommerzielles Programm geschrieben, das eine Art> Report-Generator enthielt. Mit dem gleichen Programmcode, der die> Bildschirmanzeige machte, konnte ich auch drucken! Das selbe> GDI-Interface, einziger Unterschied: der Drucker hat mehr Pixel. Und> sogar Faxen! Ist ja auch nur ein Drucker, den man per GDI ansteuern> kann.> Ein bischen Hardwarebeschleunigung gabs trotzdem: Wenn z.B. eine> Grafikkarte Kreise zeichnen konnte, konnte der Treiber die> GDI-Kreismalbefehle durchreichen. Wenn nicht, dann halt in Software -> funktioniert hat es immer.
Das besteitet auch keiner, dass es funktioniert hat. Die Frage war ja,
ob es anfangs die performanteste Lösung war.
> Und mit den Möglichkeiten kam der Bloat. Ich habe bis heute nicht> verstanden, wofür die Startleiste 3D-Unterstützung braucht. Aber ohne> DirectX war irgendwann fast alles lahm.
Das kann ich dir sagen. Ein Desktop, der die 3d GPU nutzt, bringt so
Sachen wie Expose, oder die Miniaturansicht eines Programms in der
Startleiste gratis mit, da jede Anwendung praktisch in ihre 3d
Renderfläche (eventuell eine Textur) gerendert wird und man dann nur
noch diese Renderfläche entsprechend groß, klein, draufsicht,
schrägsicht oder sonst wie einblenden muss.
Und das ganze ist dann noch durch die Hardware beschleunigt, so dass man
auf GPUs mit Hardwarebeschleunigung keine Nachteile hat.
In Software ist das dann natürlich entsprechend lahm.
Nano schrieb:> Es ging hier in diesem Thread nie darum dass man eine> Abstraktionsschicht für Drucker und eine Abstraktionsschicht für die> Grafikkarten hat, sondern es geht hier darum, dass die> Abstraktionsschicht sowohl für Drucker, als auch Grafikkarten, als auch> Plotter und sonstiges gleichermaßen geeignet ist.> Es also nur eine ist für alle möglichen Geräte.> Das gleiche ist aber auch mit vielen Abstraktionsschichten für jede> Geräteklasse möglich, die dann auf die jeweilige Geräteklasse optimiert> sind und das ist der Punkt.
Natürlich kann man für Grafikkarten, Matrixdrucker und Plotter jeweils
eine eingene Abstraktionsschicht implementieren, so dass es 3 APIs gäbe.
Da einige Drucker farbig, andere nur monochrom drucken, wäre evtl. für
letztere eine eigene Geräteklasse sinnvoll, die es erlaubt, binäre Pixel
ohne den Umweg über Farbkonvertierungen direkt an den Drucker zu
schicken. Bei den Plottern könnte man unterscheiden zwischen solchen
mit/ohne Stiftwechsel, mit festem Papierformat und Papier von der Rolle
usw. Auch die Grafikkarten könnte man in feinere Klassen unterteilen, um
jeweils die flachste Funktionsaufrufhierarchie und damit die maximale
Performance zu gewährleisten.
Wenn man das so weiterspinnen würde, hätte am Ende jedes von tausenden
existierender Gerätemodelle sein eigenes API, was zwar maximale
Performance garantieren, aber den Sinn der Abstraktion völlig ad
absurdum führen würde.
Man könnte sogar noch weiter gehen und gleich das ganze Betriebssystem
in Frage stellen, das ja nichts anderes als eine Abstraktionsschicht für
einen ganzen Computer (einschließlich Peripherie) darstellt. Wenn bspw.
Linux sowohl auf Desktop-PCs als auch auf Servern, Routern, Handys,
Industriesteuerungen u.v.m. eingesetzt wird, kann das doch unmöglich für
jede dieser Geräteklassen maximal performant sein. Also weg mit den
Betriebssystemen und hin zu Bare-Metal-Programmierung :)
Abstraktionsschichten reduzieren den Aufwand in der Softwareentwicklung
auf Kosten der Performance. Will man maximale Performance, muss man auf
Abstraktion verzichten. Das betrifft nicht nur die APIs, sondern
bedeutet auch, auf höhere Programmiersprachen zu verzichten und nur noch
in Assembler zu programmieren.
Letztendlich muss und kann jeder für sich entscheiden, auf welcher
Abstraktionsebene er seine Software am liebsten entwickelt. Das GDI hat
offensichtlich für viele Softwareentwickler Vorteile gebracht, sonst
gäbe es keine Software, die es nutzt.
Zu Amiga-Zeiten gab es einen sehr bekannten Softwareentwickler, der sich
zum Ziel gesetzt hat, das ultimative Spiel direkt von Byte 0 an zu
programmieren, das die Hardware zu 100% ausreizt und so schnell startet,
dass man nach dem Einlegen der Bootdiskette gerade noch genug Zeit hat,
die Hand zur Maus zu bewegen, bevor das Geballer losgeht.
Ergebnis: Die Entwicklung ist bis heute nicht abgeschlossen :)
Nano schrieb:> Es ging hier in diesem Thread nie darum dass man eine> Abstraktionsschicht für Drucker und eine Abstraktionsschicht für die> Grafikkarten hat, sondern es geht hier darum, dass die> Abstraktionsschicht sowohl für Drucker, als auch Grafikkarten, als auch> Plotter und sonstiges gleichermaßen geeignet ist.
Wenn ich einmal die Software für eine Ausgabe geschrieben habe, dann
schreibe ich die kein zweites mal für eine andere Ausgabe.
Wnn das OS das nicht bereit stellt, nehme ich ein Framework, dass dies
macht - irgendwo geht die Leistung drauf.
Für mich - als Entwickler - ist das am performantesten, da **meine**
Zeit gespart wird.
Sag mal Nano, was stimmt eigentlich nicht mit dir? Wir haben es
verstanden, Du findest Grafik wichtig und Drucken unnötig.
Aber stell dir vor, es gibt Leute die mussten mit diesen Geräten Arbeit
erledigen und flickerfreies Minesweeper spielte eine untergeordnete
Rolle, wie hier in diesem Thread von anderen dutzende Male erklärt.
Eine Diskussion über GDI im Jahr 2022, ich glaube sowas gibt es nur auf
mikrokontroller.net. Wobei, schön zu hören von all den Leuten die damals
DABEI waren, schade nur dass Du ihnen nicht zuhörst.
Nano schrieb:> Im Prinzip also so ne Art Objektverwaltung wie bei einem> Vektorzeichenprogramm (z.B. vergleichbar wie bei dem Vektorprogramm> Inkscape).
Ähem, nö. Es sind keine Objekte wie z.B. in Inkscape, sondern es sind
vom Prinzip her eigenständige Programme bzw. Threads, die auch (wieder
vom Prinzip her) separat verwaltet werden bzw. verwaltet werden können.
Das ist anders als bei Linux, wo die ganze grafische Pracht insgesamt
ein Aufsatz auf das eigentliche OS ist.
Nochwas: Du warst derjenige, der gefragt hatte. Und deshalb nochmal: Es
waren ökonomische Gründe, die dazu geführt hatten, daß reine GDI-Drucker
aufkamen.
W.S.
Nano schrieb:> Als Windows 95 auf den Markt kam, waren sich viele noch nicht einmal> sicher, ob jetzt IBM mit OS/2 das OS Rennen verloren hat.
Viele? Nee, nur Wenige. Und die sind dann vermutlich Linuxer geworden.
W.S.
