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?
Bist du aus einem schlimmen Traum erwacht? Warum, Warum, ... Fragen machen dumm!
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.
Stell bitte deine Fragen den Entwicklern der GDI-Drucker.
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.
:
Bearbeitet durch User
(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
Nano schrieb: > Was man aber nun hat ist ... Bahnhof. Zumindest mit dem Handy gelesen.
:
Bearbeitet durch User
> 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.
:
Bearbeitet durch User
(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 erfunden hü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. ;)
Nano schrieb: > 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) |
20 | > |
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önntest Nano schrieb: > dann würdest du kapieren, warum ich diese Fragen hier stelle Nano 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.
:
Bearbeitet durch User
(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ß.
Hat jemand mal entschieden, weil... Warum nicht! Schafft keinem 🥳😙
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.
W.S. schrieb: > 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. Da war der Keks längst gegessen https://www.computerwoche.de/a/big-blues-betriebssystem-ist-nur-noch-ein-lueckenbuesser-os-2-ibm-scheitert-bei-der-rueckeroberung-der-pc-kunden-von-gottlieb-bosch,1128132
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.