Lowlevel
Lowlevel => OS-Design => Thema gestartet von: FlashBurn am 27. September 2011, 14:32
-
Ich wollte mich gedanklich mal mit den LowLevel Konzepten einer GUI vertraut machen.
Erstmal was ich unter LowLevel verstehe. Damit meine ich wie was wann gezeichnet wird.
Hat wer dazu ein paar interessante Links/Papers die man lesen kann/sollte?
Ich "kenne" bisher folgende Konzepte:
Es wird direkt ein Bild im Grafikkartenspeicher erzeugt, sprich die einzelnen Programme haben keinen eigenen Buffer (sofern sie sich selbst keinen Anlegen), sondern bekommen von der GUI gesagt das sie doch bitte neuzeichnen sollen und welchen Bereich. Dort sollte doch der Buffer in den sie schreiben, auch mit übergeben werden und nicht so dass das Programm in einen eigenen Buffer schreibt und den dann an die GUI schickt, oder?
Das sollte so die "alte" Variante sein und vorallem die am wenigsten Speicher verbraucht, weil ja immer nur direkt in den Framebuffer geschrieben wird. Allerdings verbraucht dies auch mehr CPU Zeit.
Zu dieser Variante hätte ich gleich mal Fragen.
Ist das die Variante wie sie unter alten GUIs verwendet wurde (z.B. Windows 3.11)? Wenn ja, wie haben die Auflösungen wie 1024x768x32bit hinbekommen? Damit meine ich das wenn man davon ausgeht, dass das gesamte Bild neugezeichnet werden muss und von einem PCI-Bus ausgeht (was ja nicht unbedingt sein musste), wie konnten die 60Hz (FPS) und mehr erreichen? Das geht doch schon aus Bandbreitengründen nicht. Bei einem ISA-Bus und 640x480x32bit sollte das ja eigentlich auch nicht gehen.
Oder wurde früher einfach nur 16bit oder sogar nur 256 Farben verwendet?
Die andere Variante die ich dann kenne, nennt sich wohl Compositing (??).
Dort hat jedes Programm einen Buffer von seinem Fenster(n) und wenn die GUI ein neues Bild zeichnen möchte (und sich etwas in diesem Fenster geändert hat), erstellt das Programm nen neuen Buffer, zeichnet dort rein und schickt den Buffer an die GUI.
Vorteil ist hier das weniger CPU Zeit, aber dafür wesentlich mehr Speicher verbraucht wird.
Soweit richtig?
Was mich jetzt, insbesondere wenn ich dann irgendwann mal ne GUI designen möchte, interessiert, wie kann man dort Theming umsetzen bzw. wie wird es gemacht das jedes Fenster und die Komponenten gleich aussehen?
Ich stelle mir das so vor, dass man OS Libs nutzt um die Fenster und Elemente zu zeichnen und nicht nur in das eigentliche Fenster (ohne Rahmen, Menüleiste und sowas), sondern immer das gesamte Fenster (halt mir Rahmen, Menüleiste und sowas) zeichnet.
Theming würde dann so funktionieren, dass sich die Libs halt die Daten aus irgendwelchen Dateien holen, wie nun die Titelleiste aussehen soll, wie der Rahmen aussehen soll usw.
Ist das auch soweit richtig?
Dann, auch wenn es eigentlich außerhalb dessen liegt was ich je erreichen werde, wie läuft das mit 2D Hardwarebeschleunigung? Soweit ich es verstanden habe, gibt es die nur soweit das man Blitting in irgendeiner Weise hardwarebeschleunigt zur Verfügung hat.
Allerdings entsinne ich mich mal was gelesen zu haben, dass früher auch primitive Objekte (ala Rechteck und sowas) per Grafikkartenbefehl gezeichnet wurden?! Kann es sein, dass so höhere Auflösungen und Bittiefen möglich waren?
-
Ist das die Variante wie sie unter alten GUIs verwendet wurde (z.B. Windows 3.11)? Wenn ja, wie haben die Auflösungen wie 1024x768x32bit hinbekommen?
Grafikkarte entsprechend programmieren. Ganz einfach. :-P
Damit meine ich das wenn man davon ausgeht, dass das gesamte Bild neugezeichnet werden muss und von einem PCI-Bus ausgeht (was ja nicht unbedingt sein musste), wie konnten die 60Hz (FPS) und mehr erreichen? Das geht doch schon aus Bandbreitengründen nicht. Bei einem ISA-Bus und 640x480x32bit sollte das ja eigentlich auch nicht gehen.
Oder wurde früher einfach nur 16bit oder sogar nur 256 Farben verwendet?
Richtig in allen Punkten. Mit einer ISA-Grafikkarte kannst du - selbst wenn du 800x600 in HighColor hinkriegst - keine Vollbildvideos mit 25fps anzeigen, weil du keine 24 MB/s durch den ISA-Bus schaufeln kannst. Bei einfachen PCI-Grafikkarten ist das ähnlich.
Die 60 Hz erzeugt die Grafikkarte selbst aus ihrem Framebuffer. Selbst, wenn der bei dir in den Adressraum gemappt ist, ist das physisch auf der Grafikkarte vorhandener Speicher und der ist schnell genug, um eine gewisse Auflösung, Bildwiederholrate und Farbtiefe anzuzeigen, sonst kann die Grafikkarte den Modus nicht erzeugen. Du kannst halt nicht mit 60 Hz das Bild ändern. Damit es trotzdem hinreichend schnell ist, versucht man, Redraws möglichst zu vermeiden:
Jedes Steuerelement zeichnet sich selbst auf Anforderung neu. Es wird nur neugezeichnet, was vorher verdeckt war (wenn du z.B. ein Fenster in den Vordergrund bringst) und nicht das gesamte Fenster. Beim Verschieben verschiebst du nicht das Fenster, sondern es wird nur ein Rahmen gezeichnet, bis die Endposition feststeht. Videos werden im kleinen Fenster bei niedrigen Bildraten dargestellt. Sowas in der Art halt.
Um Bandbreite zu sparen, kann man dann auf Hardwarebeschleunigung zugreifen, z.B. BitBlit oder Hardware-Overlays (du sendest ein Video z.B. als 320x240 im YUV-Format und die Hardware plottet das auf 640x480 hochskaliert in einen mit Chroma-Keying markierten Bereich). Zu Windows 3.1-Zeiten hatte man üblicherweise nur 640x480@8, mein erster Rechner (Win95, P133) hatte 800x600@16; der eine oder andere Videoplayer konnte je nach Video auch die Auflösung automatisch runterschalten. :-)
Dort hat jedes Programm einen Buffer von seinem Fenster(n) und wenn die GUI ein neues Bild zeichnen möchte (und sich etwas in diesem Fenster geändert hat), erstellt das Programm nen neuen Buffer, zeichnet dort rein und schickt den Buffer an die GUI.
Vorteil ist hier das weniger CPU Zeit, aber dafür wesentlich mehr Speicher verbraucht wird.
Soweit richtig?
Kann man so machen. Ich würde vorschlagen, jedes Fenster kriegt einen eigenen Buffer von der GUI zugeteilt und wenn sich darin etwas geändert hat, wird die GUI über den geänderten Bereich informiert. Wie die das zeichnet, ist für die Anwendung egal (im einfachsten Fall wird dann im Framebuffer der entsprechende Bereich geändert, sofern der Fensterausschnitt überhaupt sichtbar war).
Schnell und CPU-sparsam wird das nur, wenn du genug Grafikspeicher hast, um diese Buffer dort zu lagern (du die also nicht über den Bus schicken musst) und du in der Lage bist, die Grafikkarte die Buffer selbst zeichnen zu lassen, also genug Overlays vorhanden sind. Wirklich gegeben ist das eigentlich nur bei 3D-Beschleunigung, ansonsten hast du meist nur wenige Overlays, die nicht auf jedem Head gleichzeitig sein können und nur komische Farbformate unterstützen. Für das Vordergrundfenster mag es die Trickserei wert sein, ich denke aber eher nicht.
Was mich jetzt, insbesondere wenn ich dann irgendwann mal ne GUI designen möchte, interessiert, wie kann man dort Theming umsetzen bzw. wie wird es gemacht das jedes Fenster und die Komponenten gleich aussehen?
Eine gemeinsame Grafikbibliothek benutzen. Steuerelemente und Dekorationen sind Anwendungssache (es sei denn, du lässt die Titelleiste vom Window Manager zeichnen), die sehen also immer dann unterschiedlich aus, wenn die Anwendungen sie auf verschiedenen Wegen zeichnen. Dagegen kannst du nichts machen. Portier lieber GTK oder Qt, statt ne eigene Lib dafür zu schreiben. Theming unterstützen die auch.
Dann, auch wenn es eigentlich außerhalb dessen liegt was ich je erreichen werde, wie läuft das mit 2D Hardwarebeschleunigung? Soweit ich es verstanden habe, gibt es die nur soweit das man Blitting in irgendeiner Weise hardwarebeschleunigt zur Verfügung hat.
Ja. Neben BitBlit gibt es aber noch Muster, Linien, Kreise, Ellipsen usw. die hardwarebeschleunigt sein können.
Allerdings entsinne ich mich mal was gelesen zu haben, dass früher auch primitive Objekte (ala Rechteck und sowas) per Grafikkartenbefehl gezeichnet wurden?! Kann es sein, dass so höhere Auflösungen und Bittiefen möglich waren?
Nein. Die Objekte müssen in den Grafikspeicher passen, du arbeitest mit Bitmap-basierten Systemen. Vektorgrafik ist schon seeehr lange out. ;-)
Gruß,
Svenska
-
Ich würde vorschlagen, jedes Fenster kriegt einen eigenen Buffer von der GUI zugeteilt und wenn sich darin etwas geändert hat, wird die GUI über den geänderten Bereich informiert.
Ich dachte da, in meiner naiven Art ;), daran asynchron zu zeichen. Soll heißen dass das Programm etwas neu zeichnen möchte und das sagt sie der GUI (mit dem entsprechendem Bereich) und die GUI entscheidet dann ob der Bereich sichtbar ist oder nicht und wenn er sichtbar ist, wird eine Nachricht an die Anwendung geschickt, dass sie einen bestimmten Bereich neu zeichnen soll. Das hätte halt den Vorteil, das wirklich nur gezeichnet wird, wenn das auch nötig ist.
Die Frage ist jetzt, kann das überhaupt so funktionieren?
Schnell und CPU-sparsam wird das nur, wenn du genug Grafikspeicher hast, um diese Buffer dort zu lagern (du die also nicht über den Bus schicken musst)
Das verstehe ich nicht ganz, da die Anwendung den Buffer ja mit Daten füllen muss, muss ja auf jeden Fall was über den Bus geschickt werden. Zumal gilt nicht noch immer dass das Schreiben in den Grafikspeicher nicht alzu schnell ist, sprich das es sich lohnt bei Doublebuffering einen Buffer (das fertige Bild) im Systemspeicher zu haben und diesen Buffer dann per BitBlt (oder halt kopieren) an die Grafikkarte zu schicken?
Steuerelemente und Dekorationen sind Anwendungssache
Naja, ich dachte da dann schon an eine Lib die so die Standardsteuerelemente (was meinst du mit Dekorationen?) beinhaltet.
(es sei denn, du lässt die Titelleiste vom Window Manager zeichnen)
Soll heißen, die Anwendung "sieht" die Titelleiste gar nicht in ihrem Buffer? Mal davon abgesehen, das ich die Idee verlockend finde (würde das was mir vorschwebt bestimmt einfacher machen), wie wird dort dann Theming umgesetzt, da das ja dann an zwei unterschiedlichen Stellen stattfinden müsste?
Neben BitBlit gibt es aber noch Muster, Linien, Kreise, Ellipsen usw. die hardwarebeschleunigt sein können.
Das war eigentlich das was ich meinte, mit das man der Grafikkarte sagen konnte, das man ein Rechteck zeichnen möchte.
Wie verhält es sich eigentlich mit FreeForm Windows und dem Feststellen was neu gezeichnet werden muss? Da kann ich ja schlecht nen Recheck für nehmen und jedes Mal zeichnen lassen (wenn man jetzt mal davon ausgeht, das es keine Buffer pro Fenster gibt) nur um festzustellen dass das Fenster dort nix zeichnet, ist ja auch doof. Geht das nur halbwegs effektiv mit nem Buffer pro Fenster (so dass man nen Farbwert festlegt, wo dann kein Zeichenbereich ist)?
-
Unter Windows greifen Anwendungen in der Regel nicht direkt auf den Buffer zu, sondern nutzen einen sogenannten Device Context. Das ist im Prinzip nur ein Handle, das die Zeichenfläche identifiziert. Man kann auch einen Device Context für das Fenster inklusive Titelleiste, Menu und Rahmen oder sogar den gesamten Bildschirm anfordern.
Ich dachte da, in meiner naiven Art ;), daran asynchron zu zeichen. Soll heißen dass das Programm etwas neu zeichnen möchte und das sagt sie der GUI (mit dem entsprechendem Bereich) und die GUI entscheidet dann ob der Bereich sichtbar ist oder nicht und wenn er sichtbar ist, wird eine Nachricht an die Anwendung geschickt, dass sie einen bestimmten Bereich neu zeichnen soll. Das hätte halt den Vorteil, das wirklich nur gezeichnet wird, wenn das auch nötig ist.
Die Frage ist jetzt, kann das überhaupt so funktionieren?
Funktioniert unter Windows mehr oder weniger so, wie du beschrieben hast. Die Anwendung ruft z.B. die Methode InvalidateRect (http://msdn.microsoft.com/en-us/library/dd145002%28v=VS.85%29.aspx) auf, um anzukündigen, das sie was neuzeichnen will. Das System schickt dann eine Nachricht (WM_PAINT (http://msdn.microsoft.com/en-us/library/dd145137%28v=VS.85%29.aspx)) an die Anwendung. Bei der Verarbeitung fordert die Anwendung den Device Context (mit BeginPaint (http://msdn.microsoft.com/en-us/library/dd183362%28v=VS.85%29.aspx)) an und nutzt ihn um zu Zeichnen. Die Anwendung setzt dann eine Reihe von Operationen auf dem Device Context ab (BitBlt (http://msdn.microsoft.com/en-us/library/dd183370%28v=VS.85%29.aspx), Rectangle (http://msdn.microsoft.com/en-us/library/dd162898%28v=vs.85%29.aspx), etc ...) Die Begrenzung auf den sichtbaren Bereich wird mit Hilfe des Device Contexts realisiert, der die entsprechenden Informationen enthält. Der Grafiktreiber hat dann die Möglichkeit nach Abschluss der Zeichenoperation (EndPaint (http://msdn.microsoft.com/en-us/library/dd162598%28v=VS.85%29.aspx)) die einzelnen Befehle zu optimieren und in der Hardware zu beschleunigen.
(es sei denn, du lässt die Titelleiste vom Window Manager zeichnen)
Soll heißen, die Anwendung "sieht" die Titelleiste gar nicht in ihrem Buffer? Mal davon abgesehen, das ich die Idee verlockend finde (würde das was mir vorschwebt bestimmt einfacher machen), wie wird dort dann Theming umgesetzt, da das ja dann an zwei unterschiedlichen Stellen stattfinden müsste?
Für den Fall, dass der Window Manager das nicht macht: Unter Windows wird der Anwendung eine andere Nachricht (WM_NCPAINT (http://msdn.microsoft.com/en-us/library/dd145212%28v=vs.85%29.aspx), NC = Non-Client Area) geschickt, wenn der Rahmen, usw. neugezeichnet werden muss. Die Anwendung kann dann einen anderen Device Context anfordern, mit dem sie außer halb des Fensters rummalen kann.
-
Funktioniert unter Windows mehr oder weniger so, wie du beschrieben hast. ...
Interessant das es unter Windows so gemacht wird, nur wird es dann nicht wirklich asynchron umgesetzt. Denn wenn eine Anwendung durch irgendeinen CPU intensiven Prozess blockiert ist, wird die GUI nicht neu gezeichnet und nimmt auch keine Befehle mehr entgegen. Das wollte ich halt voneinander trennen, so dass sowas nicht passieren kann.
Unter Windows wird der Anwendung eine andere Nachricht (WM_NCPAINT, NC = Non-Client Area) geschickt, wenn der Rahmen, usw. neugezeichnet werden muss. Die Anwendung kann dann einen anderen Device Context anfordern, mit dem sie außer halb des Fensters rummalen kann.
Also ich würde das nicht so zulassen. Wenn die Anwendung wirklich alles (inkl. Titelleiste und Rahmen) selbst zeichnen will, dann sollte sie das schon von Anfang an wissen und dem entsprechend ein Fenster ohne Titelleiste und Rahmen erzeugen.
Welchen Grund hat ein Programm außerhalb des eigenen Fensters zu zeichnen?
Das man unter Windows einen Device Context anfordern muss (was ich jetzt mal mit nem Buffer gleichsetze) wäre in meinem Design auch von Vorteil. Ich überlege nämlich noch, ob ich einmal die Variante des direkten Schreibens in den Framebuffer und des jedes Fenster seinen eigenen Buffer hat unterstütze, so dass auf Systemen mit zu wenig Speicher (keine Ahnung woran ich das dann festmachen würde) die GUI trotzdem laufen würde. Ist wie mit dem Caching, wenn genug Speicher vorhanden ist wird dieser fürs Caching genutzt.
Dadurch dass das Fenster nen Buffer vom GUI bekommt, merkt das Fenster den Unterschied auch gar nicht.
-
Interessant das es unter Windows so gemacht wird, nur wird es dann nicht wirklich asynchron umgesetzt.
Es ist auch möglich außerhalb dieser WM_PAINT-Nachricht zu zeichnen.
Also ich würde das nicht so zulassen. Wenn die Anwendung wirklich alles (inkl. Titelleiste und Rahmen) selbst zeichnen will, dann sollte sie das schon von Anfang an wissen und dem entsprechend ein Fenster ohne Titelleiste und Rahmen erzeugen.
Im Prinzip ist das auch so. Die Zeichenfläche ist begrenzt, und wird von der Anwendung vor dem Zeichnen festgelegt. Nur besteht die Möglichkeit das zur Laufzeit zu ändern.
-
Schnell und CPU-sparsam wird das nur, wenn du genug Grafikspeicher hast, um diese Buffer dort zu lagern (du die also nicht über den Bus schicken musst)
Das verstehe ich nicht ganz, da die Anwendung den Buffer ja mit Daten füllen muss, muss ja auf jeden Fall was über den Bus geschickt werden. Zumal gilt nicht noch immer dass das Schreiben in den Grafikspeicher nicht alzu schnell ist, sprich das es sich lohnt bei Doublebuffering einen Buffer (das fertige Bild) im Systemspeicher zu haben und diesen Buffer dann per BitBlt (oder halt kopieren) an die Grafikkarte zu schicken?
Du verwürfelst da zwei Dinge. Wenn ich das gesamte Fenster in einem eigenen, vorgerenderten Buffer in der Grafikkarte lagere, dann brauche ich für die Zusammenstellung des Desktops nur noch Befehle in der Art "dieses Teilrechteck an folgende Position", muss die Fensterdaten selbst also nicht mehr übertragen. Und auch wenn die Anwendung etwas ändern will, muss sie nur die Änderungen in die Grafikkarte kopieren, nicht das gesamte Fenster.
Das zweite ist, dass ein Zugriff auf den Grafikspeicher nicht besonders teuer ist, weil du den ja eh machen musst. Wenn du aber nur einen einzigen Bildschirm im Grafikspeicher lagern kannst (z.B. weil nur 4 MB Grafikspeicher), dann musst du für jedes Pixel, was du ändern möchtest, den alten Pixelwert lesen, ihn ändern, neu in die Grafikkarte kopieren. Das ist langsam. Wenn du aber jedes Fenster unabhängig vom Bildschirminhalt schon in der Grafikkarte hast, stört das nicht - die Anwendung kann ihren Fensterinhalt selbst reproduzieren und das "Compositing" braucht die fertigen Buffer nur (Hardwarebeschleunigt) übereinander zeichnen. Die Daten müssen dazu nicht durch die CPU.
quote="svenska"]Steuerelemente und Dekorationen sind Anwendungssache
Naja, ich dachte da dann schon an eine Lib die so die Standardsteuerelemente (was meinst du mit Dekorationen?) beinhaltet.[/quote]Dekoration sind Titelleiste, Schließen-Knopf, Systemmenü und sowas. Wenn eine Anwendung fürs Fensterzeichnen eine Lib benutzt, dann tut das nicht das GUI-System. Darum "Anwendungssache".
Soll heißen, die Anwendung "sieht" die Titelleiste gar nicht in ihrem Buffer? Mal davon abgesehen, das ich die Idee verlockend finde (würde das was mir vorschwebt bestimmt einfacher machen), wie wird dort dann Theming umgesetzt, da das ja dann an zwei unterschiedlichen Stellen stattfinden müsste?
Ist ne Designfrage. Beide Ansätze sind möglich. Und ja, du hättest Theming dann einmal in der Lib und einmal im Window Manager.
Wie verhält es sich eigentlich mit FreeForm Windows und dem Feststellen was neu gezeichnet werden muss?
Keine Ahnung. Ich würde sowas als Rechteck mit Transparenz betrachten. Da, wo das Fenster durchsichtig ist, muss ich nur neuzeichnen, wenn ich das Fenster gerade verschoben habe.
Geht das nur halbwegs effektiv mit nem Buffer pro Fenster (so dass man nen Farbwert festlegt, wo dann kein Zeichenbereich ist)?
Vierter Farbwert "Transparenz". Geht aber nur, wenn die Grafikkarte das unterstützt, bei 4/8/16/24 Bit Farbtiefe garnicht; du müsstest also Double-Buffering betreiben. (Solltest du ohnehin, wenn du nichts hardwarebeschleunigst. Aber nicht jedesmal den ganzen Framebuffer übertragen, sondern nur den Teil, der sich geändert hat.)
Interessant das es unter Windows so gemacht wird, nur wird es dann nicht wirklich asynchron umgesetzt. Denn wenn eine Anwendung durch irgendeinen CPU intensiven Prozess blockiert ist, wird die GUI nicht neu gezeichnet und nimmt auch keine Befehle mehr entgegen. Das wollte ich halt voneinander trennen, so dass sowas nicht passieren kann.
Der einfachste Fall ist, dass dein GUI-System von jedem Fenster einen Snapshot hat und wenn das Programm nicht antwortet, wird einfach der gezeichnet (Windows neuer als XP kann das).
Bei Wayland geht die Diskussion dahin, dass eine Anwendung das Rechteck angeben kann, wo der "Schließen"-Knopf im Fenster ist (i.d.R. in der Titelleiste rechts), damit Wayland auch bei nicht reagierender Anwendung herausfinden kann, dass der Anwender die Anwendung killen möchte. Viel mehr kannst du nicht garantieren, wenn du das Zeichnen der Anwendung selbst überlässt. Die Alternative - indirektes Rendering - ist nicht schön.
Welchen Grund hat ein Programm außerhalb des eigenen Fensters zu zeichnen?
Das hängt von der Definition der des Nullpunkts ab. Bei OS/2 ist er unten links, bei Windows und X11 ist er oben links unterhalb der Titelleiste. Die befindet sich dann außerhalb des Fensters, kann aber vom Programm selbst gezeichnet werden (wobei niemand ein Programm daran hindert, die Titelleiste "in" das Programm zu zeichnen).
Gruß,
Svenska
-
Hallo,
also mir persönlich gefällt das Konzept wo die Anwendung dazu aufgefordert wird Teile oder alles ihrer Fenster neu zu zeichnen absolut gar nicht. Ich finde es sehr viel besser wenn die Anwendung einfach immer dann wenn sie der Meinung ist das tun zu müssen ihren Fensterinhalt aktualisiert. Das kann asynchron (also ohne ein Kopplung an bestimmte Frames) geschehen oder auch synchron (also mit Kopplung an bestimmte Frames), letzteres ist z.B. für einen Video-Player von Interesse, der könnte einfach schon mal die nächsten 20 Bilder komplett im RAM entpacken und dann der GUI sagen zu welchen Zeitpunkten welches Bild sichtbar sein soll (das würde sogar funktionieren wenn die Bildwiederholrate des Videos nicht mit der Bildwiederholrate des Monitors übereinstimmt, es kommt dann eben nur zu leichtem Jitter wenn es da nicht zumindest ein glattes Verhältnis gibt). Der einzigste Nachteil dieser Methode ist der erhebliche Speicherverbrauch weil ja alle Fenster komplett vorliegen müssen, selbst wenn sie gar nicht sichtbar sind, nur bei verkleinerten Fenstern (also in die Task-Leiste zugeklappt) würde ich da eventuell ne Ausnahme machen und dann bei "wiederherstellen" eben auch die Anwendung antriggern. Es wäre aber auch eine Option selbst die Fenster immer komplett zu haben, auf diese Art wäre die GUI niemals von den Anwendungen abhängig und der User könnte alle Fenster nach belieben verschieben oder in die Task-Leiste zuklappen. Nur wenn die sichtbare Größe des Fensters verändert wird ist eine Reaktion der Anwendung erforderlich aber auch hier könnte die GUI erst mal einfach mit irgendeiner Default-Farbe vorbelegen und irgendwann füllt die Anwendung das dann mit echtem Inhalt (oder eben auch nicht, aber die GUI bliebe trotzdem voll funktionsfähig).
Die Fenster-Dekoration, sowas wie der anfassbare Rahmen oder die Titel-Leiste, sollte aber normalerweise schon von der GUI kommen (dann ist die Fläche für die die Anwendung selber zuständig ist ein wenig kleiner als die Fläche die vom Fenster insgesamt belegt wird und die Anwandung kann auch nur innerhalb des Fester-Innerem frei zeichnen, die GUI sollte bei Ausbruchsversuchen auch zuverlässig clippen), solange es trotzdem auch noch die Option gibt ein Fenster komplett ohne jegliche Dekoration zu erstellen (hier wäre dann die gesamte Fensterfläche für die Anwendung frei verfügbar, clipping sollte aber trotzdem vorhanden sein damit die Anwendung nicht woanders hin malt). Wenn die Fensterdekoration von der GUI kommt hat das auch den Vorteil das der Anwender ein Fenster verschieben oder auch einklappen/aufklappen kann ohne das die GUI von den Anwendungen abhängig wäre.
Meiner persönlichen Meinung nach ist es extrem wichtig das die GUI immer voll funktionsfähig ist egal ob die Anwendungen reagieren oder nicht. Eine GUI die das nicht gewährleisten kann ist aus meiner Sicht nicht akzeptabel. Ja ich weiß das ich jeden Tag vor genau solchen GUIs sitze, weder Windows noch der KDE oder Gnome können das.
Mit Wayland wird allem Anschein nach mehr Funktionalität in die Software verlagert obwohl die Anwendungen versuchen mehr Funktionalität in die Hardware zu verlagern (z.B. HW-beschleunigter Flash-Player im Firefox-Fenster). Auch das bei Wayland die Fensterdekoration und das Zusammenstellen des gesamten Desktops (IMHO das was man unter "Compositing" versteht) mehr in die Software verlagert wird empfinde ich persönlich als großen Rückschritt. Ich würde lieber möglichst fiele Funktionen die die Qt-Library anbietet direkt in HW realisieren (so das die Anwendung nur die Zeichenbefehle als Metadaten an die HW gibt und diese innerhalb ihres eigenen Speichers den jeweiligen Fensterinhalt in einem separatem Bereich zeichnet) um so eine möglichst hohe Performance und möglichst geringe CPU-Belastung zu erreichen. Gerade das periodische händische Umkopieren des gesamten Framebuffers von einem SW-Buffer im normalen RAM in den Video-Speicher der Grafikkarte ist deutlich aufwendiger als wenn die Grafikkarte sich die Bilddaten selber per Busmastering aus dem Speicher holt. Wenn man das Zeichnen der HW überlässt könnte man sogar bei asynchroner Darstellung absolut flicker-free erreichen indem die HW dafür sorgt das ein Zeichenbefehl entweder noch komplett ins nächste Frame kommt oder erst mit dem übernächsten Frame sichtbar wird.
Wohin sich die heutigen Plattformen bezüglich ihrer Grafikarchitektur bewegen werden wir wohl innerhalb der nächsten paar Jahre erfahren, es ist derzeit in diesem Bereich zumindest ein Umbruch im Gange.
Grüße
Erik
-
also mir persönlich gefällt das Konzept wo die Anwendung dazu aufgefordert wird Teile oder alles ihrer Fenster neu zu zeichnen absolut gar nicht.
Warum nicht?
Ich will das vorallem deswegen machen, weil es schön zu der Art und Weise des IPC passt. Denn es wird ja pro IPC Nachricht ein Thread erstellt, sprich der Thread ist nur vorhanden wenn auch wirklich was gemacht werden muss.
Zumal ich so ja erreichen will, dass die Anwendung auch wirklich nur aktiv wird, wenn sie was zeichnen muss (was sie ja nicht muss, wenn sie eh komplett verdeckt ist oder sich der geänderte Bereich in einem verdeckten Bereich befindet).
Ich finde es sehr viel besser wenn die Anwendung einfach immer dann wenn sie der Meinung ist das tun zu müssen ihren Fensterinhalt aktualisiert.
Kann sie ja, wie oben beschrieben, machen. Sie muss nur einfach eine Nachricht mit dem Bereich an die GUI schicken und diese entscheidet ob das auch wirklich nötig ist oder auf einen späteren Zeitpunkt verschoben werden kann.
Gerade das periodische händische Umkopieren des gesamten Framebuffers von einem SW-Buffer im normalen RAM in den Video-Speicher der Grafikkarte ist deutlich aufwendiger als wenn die Grafikkarte sich die Bilddaten selber per Busmastering aus dem Speicher holt.
Also man kopiert ja meistens nicht den gesamten Framebuffer (das will man ja gerade vermeiden), sondern nur das was sich geändert hat und dazu muss man auch lesen und das ist aus dem Grakaspeicher sehr langsam. Hat man Hardwarebeschleunigung nutzt man doch genau dafür BitBlt (das vergleicht doch und kopiert nur das was sich geänder hat, oder?).
-
Hallo,
also mir persönlich gefällt das Konzept wo die Anwendung dazu aufgefordert wird Teile oder alles ihrer Fenster neu zu zeichnen absolut gar nicht.
Warum nicht?
Abhängigkeit! Und Flexibilität.
Dass das Antriggern seht gut zu der Art von IPC passt stimmt natürlich auch wieder, aber das trifft auch auf periodische Events u.ä. zu (zumindest bei der Art wie ich die implementieren möchte) so das ich das nur begrenzt als Argument betrachte. Außerdem ist ja auch beim IPC der Caller-Thread, vom GUI-Prozess, so lange blockiert bis das IPC eine Antwort (den neuen Fensterinhalt) zurück liefert. Der Punkt ist einfach dass das angetriggerte Zeichnen unbekannt lange dauert und damit für eine GUI die der User jetzt bedienen möchte eigentlich nicht tragbar ist.
Das eine Anwendung wissen können sollte ob ihr Fenster überhaupt sichtbar ist ist aber auch wieder richtig. Sie könnte der GUI ja sagen das sie benachrichtigt werden möchte wenn ihr Fenster wieder sichtbar ist (selbst wenn nur zum Teil), solange bleibt einfach der Fenster-Buffer unverändert so das die GUI zumindest irgendetwas darstellen kann wenn der User das Fester plötzlich wieder vorholt. Wenn die Anwendung dann schnell ihren Fensterinhalt aktualisiert merkt der User eventuell nichts von dem alten Inhalt und wenn die Anwendung erst mal wieder von der Swap-Datei in den RAM gekratzt werden muss so ist das Fenster zumindest nicht leer und der Anwender kann die GUI auch normal bedienen. Hier wäre es noch cool wenn die Anwendung das erneute Zustellen von Bedien-Events erst wieder freischalten muss und vorher sämtliche Mausklicks und Tastendrücke einfach nur ins leere gehen damit zumindest nicht veraltete Bedienelemente (die jetzt eventuell gar keinen Sinn mehr machen) bedient werden können, aber es gibt auch Situationen wo es von Vorteil ist wenn die GUI die Bedien-Events sammelt (wenn die Anwendung gerade anderweitig beschäftigt ist) und diese von der Anwendung später bearbeitet werden können.
Ich hab bis jetzt noch nicht allzu viel Erfahrung beim programmieren von graphischen Programmen gesammelt, ich hab da nur ein paar Java-Programme mit Swing-GUI vorzuweisen, aber so wie ich mir das vorstelle (und es bei Swing auch ist) wird ein Fenster immer irgendwie in Rechtecke unterteilt, so das jedes Pixel im Fenster genau einem Rechteck zugeordnet ist, so ein Rechteck kann aber auch wieder in weitere Rechtecke unterteilt sein. Echten Inhalt gibt es aber nur bei Leaf-Nodes, ein Rechteck kann seine Fläche entweder komplett an Unter-Rechtecke weitergeben oder eben echten Inhalt darstellen. Letztendlich bleibt es dabei das jedes Pixel von genau einem Rechteck mit Farbe gefüllt wird. Wenn diese Struktur nicht nur innerhalb der Anwendung bleibt sondern die GUI das bekommt hat die Anwendung immer noch die Möglichkeit jedes Rechteck individuell mit Inhalt zu beschicken aber es besteht auch die Option in so ein Rechteck ein GIF zu legen und die GUI kann das entweder selber in Software immer wieder neu zeichnen oder lässt sich von der Hardware tatkräftig unterstützen. So ein Rechteck könnte aber auch von einem Flash-Player belegt sein der dazu noch nicht einmal im Kontext der Anwendung laufen muss sondern als externer Prozess läuft und einfach nur wie ein Plug-In in das Fenster der Applikation irgendetwas rein malt oder dafür auch Hardware-Beschleunigung in Anspruch nimmt (ohne das sich die Applikation dafür interessieren müsste). All das geht aber eben nur mit einem flexiblen Konzept das IMHO auch bedingt das nicht die GUI die Anwendungen antriggert ihre Fenster zu aktualisieren sondern das die Anwendungen das nur tun wenn es tatsächlich echte Events gibt.
Ich finde es sehr viel besser wenn die Anwendung einfach immer dann wenn sie der Meinung ist das tun zu müssen ihren Fensterinhalt aktualisiert.
Kann sie ja, wie oben beschrieben, machen. Sie muss nur einfach eine Nachricht mit dem Bereich an die GUI schicken und diese entscheidet ob das auch wirklich nötig ist oder auf einen späteren Zeitpunkt verschoben werden kann.
Das erscheint mir irgendwie umständlich. Stell Dir einfach mal ein animiertes GIF vor (um z.B. eine kleine Fortschrittsanimation anzuzeigen), da könnte doch die Anwendung sich immer per Event antriggern lassen wenn mal wieder ein neues Bild gezeichnet werden muss (die Zeitabstände müssen bei GIF nicht immer gleich sein so das hier flexiblere Events erforderlich sein können) und die Anwendung dann eben einfach ein kleines Rechteck im Fenster mit einem neuen Bild füllen lässt. Wenn alle Bilder des GIFs bereits im Grafikspeicher liegen dann muss der GUI-Treiber nur noch immer einen Pointer austauschen, das würde ich als effizient bezeichnen. Von händischem Zeichnen halte ich auch nicht sehr viel.
Hat man Hardwarebeschleunigung nutzt man doch genau dafür BitBlt (das vergleicht doch und kopiert nur das was sich geänder hat, oder?).
Vergleichen bedeutet aber auch Lesen also kann die Grafikkarte auch gleich den gesamten SW-Frame-Buffer aus dem normalen RAM einlesen und fertig.
Grüße
Erik
-
Hat man Hardwarebeschleunigung nutzt man doch genau dafür BitBlt (das vergleicht doch und kopiert nur das was sich geänder hat, oder?).
Nein, BitBlt ist im Prinzip nur ein Kopieren mittels DMA.
-
Hallo,
also mir persönlich gefällt das Konzept wo die Anwendung dazu aufgefordert wird Teile oder alles ihrer Fenster neu zu zeichnen absolut gar nicht.
Naja, wenn ich ein Fenster verschiebe, dann muss das Fenster, was da vorher (teilweise) hinter gelegen hat, davon erfahren und den Teil, der gerade freigelegt wurde, neu zeichnen. Das ist zwingend notwendig, wenn du kein Compositing betreibst. Denn dann hat das Fenstersystem einen kompletten Puffer der Anwendung und kann selbst neu zeichnen.
letzteres ist z.B. für einen Video-Player von Interesse
Eher weniger, weil die Videodarstellung in der Regel hardwarebeschleunigt gemacht wird. Wenn nicht, ist die Darstellung für vernünftiges Video ohnehin zu langsam. Übrigens: Die GUI triggert das Neuzeichnen, die Anwendung zeichnet neu und informiert die GUI über den neu gezeichneten Bereich. Das heißt nicht, dass die Anwendung das nicht aus sich selbst heraus könnte (sonst würden sich Fensterinhalte ohne externe Ereignisse nie ändern können).
Was du vorschlägst, ist Compositing.
Meiner persönlichen Meinung nach ist es extrem wichtig das die GUI immer voll funktionsfähig ist egal ob die Anwendungen reagieren oder nicht.
Die Idee, dass die Anwendung dem GUI-System mitteilt, wo die entsprechenden Buttons sitzen, finde ich garnicht so abwegig. Fakt ist, dass Anwendungen eigentlich alles über eine Library zeichnen, die entsprechende Funktionalität für Titelleisten usw. muss man nicht nochmal extra im GUI-System duplizieren. Theming ist ein Grund dafür, direktes Rendering auch - und insbesondere Spiele und Vollbildanwendungen wollen keine GUI-eigenen Titelleisten, sondern was eigenes.
Mit Wayland wird allem Anschein nach mehr Funktionalität in die Software verlagert obwohl die Anwendungen versuchen mehr Funktionalität in die Hardware zu verlagern
Guck dir das X11-Protokoll an und sage mir, ob du das gut findest. :-)
Effektiv wird ein Großteil des heute irrelevanten Desktops weggelassen und soweit zurechtgestutzt, dass der Grafiktreiber eine Menge beschleunigen kann. Das setzt aber immer einen modernen Grafiktreiber voraus, VESA ist da nicht geeignet. Die Art und Weise, wie Windows 3.1x arbeitet, ist für solch primitive Hardware optimal - aber Theming, Compositing und große Buffer sind damit nicht sinnvoll möglich.
Eine Anwendung, die mit GTK oder Qt geschrieben ist, braucht die Funktionalität, die GTK oder Qt bieten, nicht nochmal extra aus dem GUI-System benutzen. Von daher sehe ich keinen wirklichen Rückschritt.
Ich würde lieber möglichst fiele Funktionen die die Qt-Library anbietet direkt in HW realisieren
Ein Grafiktreiber und/oder ein GUI-System, das nur Qt anbietet, halte ich für ungeeignet. Die Idee, Compositing vorauszusetzen, finde ich gut - auch, wenn das bei primitiven Grafikchipsätzen heißt, dass das Bild im System-RAM zusammengesetzt und dann an die Grafikkarte geschickt werden muss.
Bei vorhandener 3D-Unterstützung sind alle Fenster nur Texturen, die man zusammenbauen kann und liegen im Grafikspeicher vor. Selbst mittelgroße Embedded Devices können das.
Hat man Hardwarebeschleunigung nutzt man doch genau dafür BitBlt (das vergleicht doch und kopiert nur das was sich geänder hat, oder?).
Nicht wirklich. Um Veränderungen feststellen zu können, brauchst du beide Daten, müsstest also allein dafür schon das ganze Bild über den Bus schieben. ;-)
Was sich geändert hat, weiß das GUI-System (und kann ein Redraw für den betroffenen Bereich anfordern) oder die Anwendung (muss nur den betroffenen Bereich neu zeichnen und die GUI informieren). Daraus ergibt sich, welche Teile überhaupt kopiert werden müssen.
Außerdem ist ja auch beim IPC der Caller-Thread, vom GUI-Prozess, so lange blockiert bis das IPC eine Antwort (den neuen Fensterinhalt) zurück liefert. Der Punkt ist einfach dass das angetriggerte Zeichnen unbekannt lange dauert und damit für eine GUI die der User jetzt bedienen möchte eigentlich nicht tragbar ist.
Das muss nicht sein. Die Antwort auf ein "bitte jetzt [32:48] bis [128:96] neu zeichnen" muss nicht mit einem Bildschirminhalt beantwortet werden. Die Antwort kommt per asynchronem Event "ich bin fertig". Das GUI-System muss dann den neuen Inhalt übertragen.
Wer redet denn von synchronem IPC? Grafische Nutzeroberflächen sind asynchron. ;-)
Das eine Anwendung wissen können sollte ob ihr Fenster überhaupt sichtbar ist ist aber auch wieder richtig.
Warum muss das die Anwendung wissen? Wenn sie keine Redraw-Events bekommt, muss sie auch nicht neu zeichnen. Die wenigsten Anwendungen müssen ihren Bildschirminhalt ständig neu aktualisieren (und Video-Player nutzen lieber eine spezielle Schnittstelle dafür).
Hier wäre es noch cool wenn die Anwendung das erneute Zustellen von Bedien-Events erst wieder freischalten muss und vorher sämtliche Mausklicks und Tastendrücke einfach nur ins leere gehen
Dagegen. Events vom Benutzer wegwerfen ist immer falsch. Wenn ich ein Fenster anklicke, was gerade beschäftigt ist, dann will ich nicht, dass ich ignoriert werde.
All das geht aber eben nur mit einem flexiblen Konzept das IMHO auch bedingt das nicht die GUI die Anwendungen antriggert ihre Fenster zu aktualisieren sondern das die Anwendungen das nur tun wenn es tatsächlich echte Events gibt.
Erstmal schließt das eine das andere ja nicht aus und zum zweiten ist der Flash-Player im Browser höchstwahrscheinlich ein Subfenster des Browsers. Selbst, wenn der Flash-Player in einem anderen Anwendungskontext läuft! Ein Redraw-Event für den betroffenen Bereich muss der Browser also einfach nur an seine Subfenster weiterleiten.
In Windows sind die meisten Steuerelemente als Fenster realisiert, sie sehen nur nicht so aus.
Stell Dir einfach mal ein animiertes GIF vor (um z.B. eine kleine Fortschrittsanimation anzuzeigen), da könnte doch die Anwendung sich immer per Event antriggern lassen
Das betrachte ich als vom Design her kaputt. Das GUI-System hat sich nicht dafür zu interessieren, was die Anwendung darstellen möchte. Spezialfälle wie Animationen kann die Anwendung selbst erledigen - entweder durch Pixelschubsen oder eine spezielle Video-API. Die Anwendung zeichnet einfach neu, was neu gezeichnet werden muss und informiert die GUI darüber. Ob das auch real auf dem Bildschirm erscheint, ist der Anwendung egal. Alles andere verlagert überflüssige Komplexität in die Anwendungen und sorgt dafür, dass alternative Darstellungsmechanismen nicht möglich sind. Der Zustand "minimiert" hat auf einem Tablet ohne Taskleiste keine Bedeutung, ebenso wie "überlappt sich mit einem anderen Fenster" bei einem Tiling Window Manager eher unmöglich ist. Warum soll die Anwendung sich darum kümmern müssen?
Nein, BitBlt ist im Prinzip nur ein Kopieren mittels DMA.
Wobei je nach Hardware auch eine Bitoperation gemacht werden kann (z.B. XOR beim Cursor).
Gruß,
Svenska
-
Stell Dir einfach mal ein animiertes GIF vor (um z.B. eine kleine Fortschrittsanimation anzuzeigen), da könnte doch die Anwendung sich immer per Event antriggern lassen wenn mal wieder ein neues Bild gezeichnet werden muss (die Zeitabstände müssen bei GIF nicht immer gleich sein so das hier flexiblere Events erforderlich sein können) und die Anwendung dann eben einfach ein kleines Rechteck im Fenster mit einem neuen Bild füllen lässt. Wenn alle Bilder des GIFs bereits im Grafikspeicher liegen dann muss der GUI-Treiber nur noch immer einen Pointer austauschen, das würde ich als effizient bezeichnen. Von händischem Zeichnen halte ich auch nicht sehr viel.
Also irgendwann mussten ja die einzelnen Bilder des GIFs mal händisch gezeichnet werden um die Buffer anzulegen. Dann kommt noch hinzu, dass das was du beschreibst doch auch möglich ist, wenn die GUI die Anwendung antriggert. Denn es bleibt dabei, warum sollte man Buffer austauschen, wenn das Fenster gar nicht sichtbar ist.
Die Anwendung erstellt halt einfach ihre Buffer, speichert die meinetwegen in einer Liste, mit Zeitwerten und die Anwendung sendet zu jeder Zeit (wo sich der Inhalt ändert) eine Nachricht an die GUI, das sich was verändert hat und setzt den Zeiger auf das nächste Element in der Liste. Die GUI entscheidet jetzt aber, ob es Sinn macht einen neuen Buffer von der Anwendung anzufordern und nur dann wird auch ein Buffer übertragen. Das nenne ich effizient ;)
Die Idee, dass die Anwendung dem GUI-System mitteilt, wo die entsprechenden Buttons sitzen, finde ich garnicht so abwegig.
Welchen Vorteil hätte das? Ich sehe da nur mehr Aufwand in der GUI, der sonst in der Anwendung wäre.
Fakt ist, dass Anwendungen eigentlich alles über eine Library zeichnen, die entsprechende Funktionalität für Titelleisten usw. muss man nicht nochmal extra im GUI-System duplizieren. Theming ist ein Grund dafür, direktes Rendering auch - und insbesondere Spiele und Vollbildanwendungen wollen keine GUI-eigenen Titelleisten, sondern was eigenes.
Ich habe mich noch nicht mit solchen Libs beschäftigt, aber wie setzt man es dann um das alle Anwendungen gleich aussehen? Ich möchte eigentlich nicht, dass jede Anwendung ne andere Titelleiste (und damit wahrscheinlich auch noch andere Position der Buttons hat (schließen und sowas)) und andere Bedienelemente hat. Das sollte schon alles einheitlich sein.
Oder erreicht man das durch Theming?
Effektiv wird ein Großteil des heute irrelevanten Desktops weggelassen und soweit zurechtgestutzt, dass der Grafiktreiber eine Menge beschleunigen kann. Das setzt aber immer einen modernen Grafiktreiber voraus, VESA ist da nicht geeignet. Die Art und Weise, wie Windows 3.1x arbeitet, ist für solch primitive Hardware optimal - aber Theming, Compositing und große Buffer sind damit nicht sinnvoll möglich.
Naja, seien wir mal ehrlich, wer von uns rechnet schon damit, dass er nen hardwarebeschleunigten Grafiktreiber haben wird? Man wird immer irgendwie auf VESA zurück greifen müssen.
Deswegen wollte ich ja auch beide Varianten unterstützen.
Was sich geändert hat, weiß das GUI-System
Da bin ich mir gerade nicht so sicher. Sagen wir mal es wird ein Button gedrückt (und der Button wird dann gedrückt dargestellt), dann wird die GUI, von der Anwendung, zwar benachrichtigt dass sich der Bereich um den Button geändert hat, aber das heißt nicht, dass alle Pixel ne andere Farbe bekommen. Das bekommt man nur durch vergleichen heraus. In nem anderen Forum (osdev.org) wird halt empfohlen zu vergleichen (im Systemram) und nur die wirklich geänderten Werte an die Graka zu schicken, weil es sonst zu langsam ist.
-
Hallo,
Die Idee, dass die Anwendung dem GUI-System mitteilt, wo die entsprechenden Buttons sitzen, finde ich garnicht so abwegig.
Welchen Vorteil hätte das? Ich sehe da nur mehr Aufwand in der GUI, der sonst in der Anwendung wäre.
Wenn die Titelleiste von der Anwendung gezeichnet wird und die Anwendung nicht auf Ereignisse reagiert, dann weiß die GUI wenigstens, wenn der Nutzer die Anwendung schließen möchte und kann sie z.B. töten.
Ich habe mich noch nicht mit solchen Libs beschäftigt, aber wie setzt man es dann um das alle Anwendungen gleich aussehen?
Indem alle Anwendungen die gleiche Lib verwenden. Effektiv gibt es zwei große Bibliotheken (GTK und Qt) und durch Theming kann man die gleich aussehen lassen.
Die zweite Möglichkeit ist die Apple-Variante: Es gibt Design-Richtlinien und Programme, die die nicht erfüllen, werden nicht zertifiziert. :-) Das garantiert "überall gleiches Aussehen", ist aber für ein Hobby-OS ungeeignet.
Ich möchte eigentlich nicht, dass jede Anwendung ne andere Titelleiste (und damit wahrscheinlich auch noch andere Position der Buttons hat (schließen und sowas)) und andere Bedienelemente hat. Das sollte schon alles einheitlich sein.
Es gibt Programme, für die ein anderes Aussehen durchaus sinnvoll ist (z.B. Spiele, die haben keine Titelleiste und der Schließen-Button ist im Hauptmenü).
Alle Programme, die eine bestimmte Lib nutzen, kannst du über die Einstellungen dieser Lib themen und dann sehen sie gleich aus.
Naja, seien wir mal ehrlich, wer von uns rechnet schon damit, dass er nen hardwarebeschleunigten Grafiktreiber haben wird? Man wird immer irgendwie auf VESA zurück greifen müssen.
Nicht unbedingt, aber wenn du ein modernes GUI-System haben willst, dann wird VESA nur suboptimal laufen und wenn du ein VESA-optimiertes GUI-System willst, dann kannst du Compositing direkt vergessen. Du hast die Wahl.
Was sich geändert hat, weiß das GUI-System
Da bin ich mir gerade nicht so sicher. Sagen wir mal es wird ein Button gedrückt (und der Button wird dann gedrückt dargestellt), dann wird die GUI, von der Anwendung, zwar benachrichtigt dass sich der Bereich um den Button geändert hat, aber das heißt nicht, dass alle Pixel ne andere Farbe bekommen.
Wenn du einen Button drückst, dann sagt der Button seinem übergeordnetem Fenster "Ich muss mich jetzt neu zeichnen." Das macht die Library, die die Widgets zur Verfügung stellt. Das übergeordnete Fenster wartet dann ab, bis der Button sich neu gezeichnet hat und sagt dem GUI-System "Hier, folgendes Rechteck wurde neu gezeichnet." Das GUI-System guckt dann nach, ob der Teilbereich überhaupt sichtbar ist und zeichnet das - falls notwendig - auf den Bildschirm. Da wird nicht verglichen.
Jedes Steuerelement weiß selbst, wie es sich zeichnet. Die GUI ist nur dafür verantwortlich, das auch in den Framebuffer zu kopieren, falls das notwendig ist.
Das bekommt man nur durch vergleichen heraus. In nem anderen Forum (osdev.org) wird halt empfohlen zu vergleichen (im Systemram) und nur die wirklich geänderten Werte an die Graka zu schicken, weil es sonst zu langsam ist.
Wozu vergleichen? Die Anwendung sagt dem GUI-System doch, was sich geändert hat. Die wird's schon wissen, nochmal extra einen Vergleichsschritt drüberzuwerfen ist überflüssig.
Gruß,
Svenska
-
Wenn die Titelleiste von der Anwendung gezeichnet wird und die Anwendung nicht auf Ereignisse reagiert, dann weiß die GUI wenigstens, wenn der Nutzer die Anwendung schließen möchte und kann sie z.B. töten.
Ich weiß gerade nicht wie Windows das macht, aber funktioniert das ja auch, wenn die Anwendung nicht reagiert, stellt Windows das irgendwie fest (vorallem wenn man dann ein paar Mal klickt) und fragt ob das Programm beendet werden soll.
Bei Theming kann man ja auch die Lage der Titelleistebuttons (schließen und sowas) ändern. Von daher wäre es eventuell ausreichend, wenn man Lage und Größe der 4 (unter Windows) Buttons (Systemmenü, Minimieren, Maximieren und Schließen) der GUI mitteilt.
Dann würde ich es aber so machen, dass es Grundsätzlich nur Fenster ohne Titelleiste und Rahmen gibt und dass das alles die Anwendung machen muss.
Es gibt Programme, für die ein anderes Aussehen durchaus sinnvoll ist (z.B. Spiele, die haben keine Titelleiste und der Schließen-Button ist im Hauptmenü).
Naja, dafür würde es dann doch 2 Typen von Fenster geben, einmal mit Rahmen und Titelleiste und einmal ohne Rahmen und Titelleiste.
Nicht unbedingt, aber wenn du ein modernes GUI-System haben willst, dann wird VESA nur suboptimal laufen und wenn du ein VESA-optimiertes GUI-System willst, dann kannst du Compositing direkt vergessen. Du hast die Wahl.
Windows und Linux haben auch noch VESA Treiber und beide nutzen Compositing. Zumal ich deswegen ja mit dem Gedanken spiele die GUI so zu entwerfen, dass zur Laufzeit entschieden wird, welche Variante (immer neuzeichnen direkt in den Framebuffer oder Compositing) genutzt wird.
Wozu vergleichen? Die Anwendung sagt dem GUI-System doch, was sich geändert hat. Die wird's schon wissen, nochmal extra einen Vergleichsschritt drüberzuwerfen ist überflüssig.
Es ging darum, dass das Schreiben in den Grakaspeicher nicht besonders schnell ist und das man deswegen so wenig Daten wie möglich zur Graka schicken sollte. Deswegen kam das mit dem Vergleichen und wirklich nur die Pixel senden die sich geändert haben.
Mit meinem Bsp. wollte ich darauf hinaus, das nur weil sich der Bereich des Buttons geändert hat, es noch lange nicht heißt das sich wirklich alle Pixel in dem Bereich geändert haben.
Anderes Bsp. du scrollst eine Webpage (z.B. das Forum) und das gesamte Fenster muss neugezeichnet werden. Bei den großen Flächen mit der gleichen Farbe, kannst du einiges an Bandbreite einsparen, indem du nur die Pixel schreibst, wo sich die Farbe auch verändert hat und bei diesem Bsp. wären das ne Menge Pixel die man nicht ändern müsste.
-
Bei Theming kann man ja auch die Lage der Titelleistebuttons (schließen und sowas) ändern. Von daher wäre es eventuell ausreichend, wenn man Lage und Größe der 4 (unter Windows) Buttons (Systemmenü, Minimieren, Maximieren und Schließen) der GUI mitteilt.
Dann würde ich es aber so machen, dass es Grundsätzlich nur Fenster ohne Titelleiste und Rahmen gibt und dass das alles die Anwendung machen muss.
Davon rede ich die ganze Zeit.
Windows und Linux haben auch noch VESA Treiber und beide nutzen Compositing. Zumal ich deswegen ja mit dem Gedanken spiele die GUI so zu entwerfen, dass zur Laufzeit entschieden wird, welche Variante (immer neuzeichnen direkt in den Framebuffer oder Compositing) genutzt wird.
Nein, beide Systeme haben kein Compositing, wenn der VESA-Treiber verwendet wird...
Es ging darum, dass das Schreiben in den Grakaspeicher nicht besonders schnell ist und das man deswegen so wenig Daten wie möglich zur Graka schicken sollte. Deswegen kam das mit dem Vergleichen und wirklich nur die Pixel senden die sich geändert haben.
Bringt meiner Meinung nach wenig, zumindest kenne ich keinen Fall, wo man das wirklich tut.
Anderes Bsp. du scrollst eine Webpage (z.B. das Forum) und das gesamte Fenster muss neugezeichnet werden. Bei den großen Flächen mit der gleichen Farbe, kannst du einiges an Bandbreite einsparen, indem du nur die Pixel schreibst, wo sich die Farbe auch verändert hat und bei diesem Bsp. wären das ne Menge Pixel die man nicht ändern müsste.
Es ist aber nicht Aufgabe des GUI-Systems, das nachträglich festzustellen, sondern Aufgabe der Anwendung, nur die entsprechenden Rechtecke zu übertragen. Ist jedenfalls meine Meinung.
-
Davon rede ich die ganze Zeit.
Schön das wir uns verstehen :D
Ist es beim Theming auch möglich die Form der Fenster festzulegen? Oder anders, wie Schwierig wäre das, so schwierig das es sich wieder lohnen würde, die Anwendungen nur direkt ins Fenster zeichnen zu lassen und Rahmen und Titelleiste der GUI zu überlassen?
Nein, beide Systeme haben kein Compositing, wenn der VESA-Treiber verwendet wird...
Also können beide Compositing und die alte Variante (so wie ich es eigentlich auch geplant habe)?!
Es ist aber nicht Aufgabe des GUI-Systems, das nachträglich festzustellen, sondern Aufgabe der Anwendung, nur die entsprechenden Rechtecke zu übertragen. Ist jedenfalls meine Meinung.
Da hast du schon recht.
Man könnte das ja im VESA-Treiber machen. Der hat dann immer 2 Buffer mit dem Bildinhalt, einmal den mit dem vorherigen Bild und einmal den mit dem neuen Bild. So kann er dann vergleichen und nur das schreiben was sich wirklich geändert hat.
Solch eine Variante sollte man eigentlich sogar grundsätzlich machen, weil man will bestimmt nicht jedes Mal den Bereich vom Mauszeiger neuzeichnen lassen, indem man sich die Daten wieder von den Anwendungen holt, sondern dass man den Mauszeiger immer als letztes überträgt, aber nicht mit in den Buffern speichert.
-
Ist es beim Theming auch möglich die Form der Fenster festzulegen? Oder anders, wie Schwierig wäre das, so schwierig das es sich wieder lohnen würde, die Anwendungen nur direkt ins Fenster zeichnen zu lassen und Rahmen und Titelleiste der GUI zu überlassen?
Wie wäre es, wenn du einfach alle Dekorationen den Anwendungen überlässt? Wenn die vorhandene Farbtiefe einen Alphakanal unterstützt (bei 32 Bit ist das möglich, sonst nicht), dann kann die Anwendung einen Teil ihres Fensters transparent machen und das Problem ist gelöst. :-)
Ansonsten bin ich grundsätzlich eher gegen Freiform-Fenster.
Nein, beide Systeme haben kein Compositing, wenn der VESA-Treiber verwendet wird...
Also können beide Compositing und die alte Variante (so wie ich es eigentlich auch geplant habe)?!
Ja. Aber zwei Systeme parallel zu unterstützen wäre mir zuviel Aufwand. Ich würde wahrscheinlich ausschließlich Compositing unterstützen, der VESA-Treiber hätte dann halt Pech und wäre etwas langsamer als notwendig.
weil man will bestimmt nicht jedes Mal den Bereich vom Mauszeiger neuzeichnen lassen, indem man sich die Daten wieder von den Anwendungen holt, sondern dass man den Mauszeiger immer als letztes überträgt, aber nicht mit in den Buffern speichert.
Naja, du kannst den Mauszeiger mit XOR drüberzeichnen und wenn er sich wegbewegt nochmal - dann sollte das ursprüngliche Bild wieder rauskommen. Jede Grafikkarte mit ein bisschen 2D unterstützt Hardware-Cursor, allerdings hat zumindest X11 damit öfter mal Probleme gehabt. :-)
Gruß,
Svenska
-
Wenn die vorhandene Farbtiefe einen Alphakanal unterstützt (bei 32 Bit ist das möglich, sonst nicht), dann kann die Anwendung einen Teil ihres Fensters transparent machen und das Problem ist gelöst.
Problem ist, ich kann mir nicht vorstellen, das man das halbwegs effizient lösen kann. Denn dann müsste ich das oberste Fenster fragen, ob da wo sich die Maus befindet (und am besten gerade geklickt hat), das Fenster richtig ist oder nicht und wenn nicht, müsste ich zum nächst tieferen Fenster gehen usw.
Das muss sich doch auch anders lösen lassen.
Ansonsten bin ich grundsätzlich eher gegen Freiform-Fenster.
Naja, ich bin ja auch der Meinung nen Fenster kann ruhig ne rechteckige Form haben, aber da ich von dem BeOS/Haiku Design angetan bin (und das auch so umsetzen wollte), bräuchte ich halt sowas und da bietet sich dann an, dass die Anwendung nix mit Rahmen und Titelleiste zu tun hat.
Wenn ich mal die Lust dazu habe, versuche ich mal im Haiku-Source den Code dafür zu finden.
Ja. Aber zwei Systeme parallel zu unterstützen wäre mir zuviel Aufwand. Ich würde wahrscheinlich ausschließlich Compositing unterstützen, der VESA-Treiber hätte dann halt Pech und wäre etwas langsamer als notwendig.
Problem hierbei ist, würdest du dich wirklich damit abgeben, dass deine GUI dann auf den meisten System wahrscheinlich langsam bis zu langsam wäre (keine Ahnung wie groß der Unterschied ist)? Denn genügend Treiber wirst du wohl nicht zusammen bekommen, es sei denn du schaffst dir nen Layer, so dass du z.B. Linuxtreiber kompilieren und dann nutzen kannst (wie heißt die neue Schnittstelle für Grafiktreiber doch gleich, ich komm gerade nicht drauf?).
-
Naja, ich bin ja auch der Meinung nen Fenster kann ruhig ne rechteckige Form haben, aber da ich von dem BeOS/Haiku Design angetan bin (und das auch so umsetzen wollte), bräuchte ich halt sowas und da bietet sich dann an, dass die Anwendung nix mit Rahmen und Titelleiste zu tun hat.
Oder die GUI-Lib erzeugt einfach ein eigenes Fenster für die Titelleiste, die nur gemeinsam verschoben werden, dann ist das Problem auch beseitigt. Ein Fenster muss nicht ein Rechteck mit Rahmen und Titelleiste sein - effektiv ist ein Fenster etwas, was ein Fenster-Handle anbieten kann. GTK kann das selbst, das muss die GUI nicht anbieten.
(wie heißt die neue Schnittstelle für Grafiktreiber doch gleich, ich komm gerade nicht drauf?).
Gallium3D.
Fakt ist, mit dem VESA-Treiber machst du keinen Anwender glücklich. Entweder, du baust dir einen modernen Desktop - oder du lässt es sein. Eine Mischung ist in jedem Fall Mist, und zwei Codepfade pflegen halte ich für unsinnig. Besonders bei so komplexem Zeug wie GUI und einem Hobby-OS.
Gruß,
Svenska
-
Fakt ist, mit dem VESA-Treiber machst du keinen Anwender glücklich. Entweder, du baust dir einen modernen Desktop - oder du lässt es sein.
Das würde ja heißen, dass alle Hobby-OSs keine GUIs haben dürfen, weil man einfach nicht für jede Graka nen Treiber haben kann.
Außerdem ist nen VESA-Treiber im Endeffekt nix anderes als nen Framebuffer-Device? Sowas wird doch auch ohne Probleme unter Linux eingesetzt.
Eine Mischung ist in jedem Fall Mist, und zwei Codepfade pflegen halte ich für unsinnig. Besonders bei so komplexem Zeug wie GUI und einem Hobby-OS.
Kann sein, dass ich zwecks nicht vorhandener Erfahrung, die ganze Sache gewaltig unterschätze, aber ich wollte es ja so machen, das die Anwendung der GUI sagt, welcher Bereich neugezeichnet werden muss und die GUI sendet dann ne Nachricht an die Anwendung das sie nen Redraw in einem Bestimmten Bereich machen soll. Diese Nachricht beinhaltet aber auch den Buffer wo die neuen Daten reinsollen.
Damit erreiche ich, das ich der Anwendung als Buffer einfach den Framebuffer der Graka geben kann oder den Framebuffer den ich im Systemram habe für den VESA-Treiber.
Auf jeden Fall merkt die Anwendung nix davon und der Aufwand für die GUI sollte sich auch in Grenzen halten oder übersehe ich da was?
-
Fakt ist, mit dem VESA-Treiber machst du keinen Anwender glücklich. Entweder, du baust dir einen modernen Desktop - oder du lässt es sein.
Das würde ja heißen, dass alle Hobby-OSs keine GUIs haben dürfen, weil man einfach nicht für jede Graka nen Treiber haben kann.
Hervorhebung von mir. :-)
-
Gut, dann sage doch mal was nen modernen Desktop modern macht (du denkst dabei doch an bestimmte Features oder?).
Auf meine Frage ob das Linux mit seinen Framebuffer-Devices nicht auch macht, hast du leider nicht geantwortet.
-
Hallo,
Naja, seien wir mal ehrlich, wer von uns rechnet schon damit, dass er nen hardwarebeschleunigten Grafiktreiber haben wird?
Also ich rechne schon damit, zumindest das zusammensetzen des gesamten Frames auf vielen kleinen unabhängigen und flexiblen Rechtecken möchte ich schon in HW unterstützen (also HW-beschleunigtes 2D, ausreichend Video-RAM sollte ja bei den heutigen bzw. zukünftigen Preisen für DRAM-Chips kein Problem darstellen). Falls ich an meiner Plattform mal mehr haben will als eine Konsole per RS232 dann muss ich mich eh nach geeigneten Grafikkontrollern umsehen, ich hab da auch schon mal einen sehr interessanten Kandidaten gefunden der eigentlich alles kann was mir vorschwebt und für den es auch vollständige Datenblätter gibt.
also mir persönlich gefällt das Konzept wo die Anwendung dazu aufgefordert wird Teile oder alles ihrer Fenster neu zu zeichnen absolut gar nicht.
Naja, wenn ich ein Fenster verschiebe, dann muss das Fenster, was da vorher (teilweise) hinter gelegen hat, davon erfahren und den Teil, der gerade freigelegt wurde, neu zeichnen.
Nö, in meiner (sicherlich naiven) Vorstellung ist auch das verdeckte (oder verkleinerte) Fenster in der GUI immer komplett vorhanden (ja ich weiß dass das Speicher kostet) und kann daher sofort ohne mitwirken der Applikation dargestellt werden. Im Optimum sollten möglichst alle Fenster im Video-RAM der Grafikkarte vorhanden sein (und auch immer dort aktualisiert werden) so dass das verschieben von Fenstern nur das Ändern von ein paar Koordinaten im "Frame-Descriptor-Tree" ist und effektiv keine Pixel-Daten übertragen werden müssen (zumindest solange sich nicht auch wirklich Bildinhalt ändert). Klar wäre es doof wenn man plötzlich mit HW konfrontiert ist die das nicht beherrscht und man dann alles das aufwendig in SW nachbilden muss aber irgendwo muss man IMHO eine untere Schwelle ansetzen und das was mir vorschwebt sollte eigentlich seit 10 Jahren keinen käuflich erwerbbaren (PCI/PCIe-)Grafikkontroller vor erhebliche Hindernisse stellen. Selbst teil-transparente Fenster stellen in dem System kein Problem dar (von der zusätzlichen Speicherbandbreite im Video-RAM fürs mehrfache Lesen pro Pixel mal abgesehen).
Was du vorschlägst, ist Compositing.
Ganz genau, das will ich.
Die Idee, dass die Anwendung dem GUI-System mitteilt, wo die entsprechenden Buttons sitzen, finde ich garnicht so abwegig.
Ja, dem kann ich zustimmen. Wenn man Fenster ohne Dekoration anbieten möchte (und ich denke das ist für eine GUI Pflicht und bei einer entsprechenden GUI-Library eventuell sogar die Regel) dann muss es da zumindest ein paar grundlegende Bedienelemente geben die immer funktionieren.
Guck dir das X11-Protokoll an und sage mir, ob du das gut findest. :-)
Ich hab mir X11 vor etlichen Jahren nur mal kurz und nur recht oberflächlich angesehen. Vom Konzept her ist das wimre gar nicht mal so verkehrt wenn wohl auch die Umsetzung nicht mehr so ganz Zeitgemäß ist.
Eine Anwendung, die mit GTK oder Qt geschrieben ist, braucht die Funktionalität, die GTK oder Qt bieten, nicht nochmal extra aus dem GUI-System benutzen. Von daher sehe ich keinen wirklichen Rückschritt.
GTK und Qt machen eigentlich alles in SW und liefern an die GUI nur noch ein fertiges Bitmap, genau das finde ich persönlich eher ungeschickt und von der Performance her auch suboptimal. Ich behaupte mal mit einer passenden HW-Unterstützung und der Fähigkeit von der Grafik-Library diese Möglichkeiten auch durch das GUI-System hindurch effizient nutzen zu können sollte man einen schicken und modernen KDE-Desktop auch mit nem 100 MHz Pentium noch flüssig bedienbar machen können.
Wer redet denn von synchronem IPC? Grafische Nutzeroberflächen sind asynchron. ;-)
Hm, stimmt. Aber wie ich den Bild-Speicher von den Anwendungen in die GUI bekomme ohne dafür die Anwendungen länger als nötig zu blockieren und ohne kopieren zu müssen hab ich mir auch noch nicht überlegt.
Hier wäre es noch cool wenn die Anwendung das erneute Zustellen von Bedien-Events erst wieder freischalten muss und vorher sämtliche Mausklicks und Tastendrücke einfach nur ins leere gehen
Dagegen. Events vom Benutzer wegwerfen ist immer falsch. Wenn ich ein Fenster anklicke, was gerade beschäftigt ist, dann will ich nicht, dass ich ignoriert werde.
Gut, auch wieder wahr, den Svenska zu ignorieren wäre einfach unhöflich. Ich denke man merkt schon deutlich das ich von GUI noch nicht sonderlich viel Ahnung hab, vielleicht sollte ich dieses Thema auch erst mal da lassen wo es für mich momentan eigentlich hin gehört, ganz hinten.
In Windows sind die meisten Steuerelemente als Fenster realisiert, sie sehen nur nicht so aus.
Das kenne ich von Swing auch, da wurde fast alles von JPane (ich hoffe mein Gedächtnis lässt mich da jetzt nicht im Stich) abgeleitet. So eine JPane kann entweder eigenen Bild-Inhalt haben oder eine/mehrere JPane wieder als Unter-Elemente beherbergen.
Stell Dir einfach mal ein animiertes GIF vor (um z.B. eine kleine Fortschrittsanimation anzuzeigen), da könnte doch die Anwendung sich immer per Event antriggern lassen
Das betrachte ich als vom Design her kaputt.
Ich glaube da hast Du mich missverstanden. Ich meine das die Anwendung sich z.B. von einem System-Timer regelmäßig antriggern lassen kann, sowas soll nicht Aufgabe der GUI sein, um dann den Bildinhalt bei der GUI zu aktualisieren (also neu zeichnen), eben je nach dem was für das entsprechende darzustellende Objekt erforderlich ist. Für richtige Videos sollte natürlich auch ne spezial-API vorhanden sein, obwohl ich schon der Meinung bin das das grundsätzlich auch ohne spezial-API möglich sein sollte solange die RAM-Performance und auch die PCI-Performance dabei gut mitspielen (was heute selbst für Full-HD als gegeben zu betrachten ist). Wenn Du das immer noch als "kaputt" betrachtest dann erkläre mir das Bitte mal.
Anderes Bsp. du scrollst eine Webpage (z.B. das Forum) und das gesamte Fenster muss neugezeichnet werden. Bei den großen Flächen mit der gleichen Farbe, kannst du einiges an Bandbreite einsparen, indem du nur die Pixel schreibst, wo sich die Farbe auch verändert hat und bei diesem Bsp. wären das ne Menge Pixel die man nicht ändern müsste.
Scrollen würde ich persönlich ganz anders machen. Ich würde das komplette Bild in den Video-Speicher laden und der Grafikkarte nur noch sagen "da liegt ein Bild mit den Ausmaßen X:Y an Offset Z im Video-RAM, zeichne davon den Teilausschnitt von U:V mit H:W ins Frame an A:B". Wenn gescrollt wird muss dann immer nur U:V angepasst werden und fertig. Ich persönlich empfinde es als arg eklig das ich im Browser immer solche hässlichen Ruckler sehen muss nur weil ich dort mal ein Bild mit ein paar mehr Megapixeln in 1:1 Darstellung umherscrolle. Sollte das Bild deutlcich größer sein als der Video-RAM es fassen kann dann muss es eben gekachelt werden, solange eine Kachel immer mindestens so groß ist wie die Darstellungsfläche im Fenster müssen auch nur mindestens 4 Kacheln im Video-RAM vorhanden sein (mehr schadet natürlich nicht um Rucklern beim weiterscrollen vorzubeugen). Heutzutage ist der Video-RAM deutlich größer als nötig wäre den Monitor-Inhalt mehr als 10 mal zu enthalten, stellt also alles kein Problem dar.
Wenn die vorhandene Farbtiefe einen Alphakanal unterstützt (bei 32 Bit ist das möglich, sonst nicht), dann kann die Anwendung einen Teil ihres Fensters transparent machen und das Problem ist gelöst.
Problem ist, ich kann mir nicht vorstellen, das man das halbwegs effizient lösen kann. Denn dann müsste ich das oberste Fenster fragen, ob da wo sich die Maus befindet (und am besten gerade geklickt hat), das Fenster richtig ist oder nicht und wenn nicht, müsste ich zum nächst tieferen Fenster gehen usw.
Das muss sich doch auch anders lösen lassen.
Aber so wird das gemacht. Die GUI sendet den Event an das oberste Fenster und dieses behandelt den entweder selber oder gibt ihn der GUI zurück mit der klaren Info den eine Ebene tiefer zu reichen, anders kann man das mMn nicht lösen.
Gut, dann sage doch mal was nen modernen Desktop modern macht (du denkst dabei doch an bestimmte Features oder?).
Für mich persönlich wäre z.B. wichtig das ein Video weiter läuft auch wenn ich das entsprechende Fenster verschiebe und zwar ohne hässliche Artefakte (sowas wie das in dem Bereich wo das Fenster hingeschoben wurde nicht gleich das Video zu sehen ist oder das die Fenster(-Bereiche) die zum Vorschein kommen Weiße Flächen sind). Das alles sollte eigentlich schon seit über 10 Jahren nicht mehr auftreten, die HW kann das auf jeden Fall, es mangelt meiner Meinung nach nur an geeigneter Software.
Grüße
Erik
-
Nö, in meiner (sicherlich naiven) Vorstellung ist auch das verdeckte (oder verkleinerte) Fenster in der GUI immer komplett vorhanden (ja ich weiß dass das Speicher kostet) und kann daher sofort ohne mitwirken der Applikation dargestellt werden. Im Optimum sollten möglichst alle Fenster im Video-RAM der Grafikkarte vorhanden sein (und auch immer dort aktualisiert werden) so dass das verschieben von Fenstern nur das Ändern von ein paar Koordinaten im "Frame-Descriptor-Tree" ist und effektiv keine Pixel-Daten übertragen werden müssen (zumindest solange sich nicht auch wirklich Bildinhalt ändert).
Das wäre aber nicht mehr effizient. Denn du würdest zeichnen ohne das es Sinn macht. Wieso z.B. den Speicherbus mit einer GIF-Animation belasten, obwohl das Fenster nicht zu sehen ist und das für vllt ein paar Minuten?
Wenn ich mir überlege, was das auch an CPU Leistung kosten würde, wenn alle meine Tabs ständig am zeichnen wären bzw was sich da einsparen lässt. Anderes Bsp wäre wenn der Bildschirm aus wäre oder der Bildschirmschoner an wäre, da würden bei dir die Anwendungen alle schön weiterzeichnen. Auch ein blinkender Cursor muss nicht ständig aktualisiert werden, wenn das Fenster eh nicht zu sehen ist.
Ansonsten geht das auch mit Compositing. Nur das trotzdem nur gezeichnet wird, wenn auch nötig.
Scrollen würde ich persönlich ganz anders machen. Ich würde das komplette Bild in den Video-Speicher laden und der Grafikkarte nur noch sagen "da liegt ein Bild mit den Ausmaßen X:Y an Offset Z im Video-RAM, zeichne davon den Teilausschnitt von U:V mit H:W ins Frame an A:B". Wenn gescrollt wird muss dann immer nur U:V angepasst werden und fertig. Ich persönlich empfinde es als arg eklig das ich im Browser immer solche hässlichen Ruckler sehen muss nur weil ich dort mal ein Bild mit ein paar mehr Megapixeln in 1:1 Darstellung umherscrolle. Sollte das Bild deutlcich größer sein als der Video-RAM es fassen kann dann muss es eben gekachelt werden, solange eine Kachel immer mindestens so groß ist wie die Darstellungsfläche im Fenster müssen auch nur mindestens 4 Kacheln im Video-RAM vorhanden sein (mehr schadet natürlich nicht um Rucklern beim weiterscrollen vorzubeugen). Heutzutage ist der Video-RAM deutlich größer als nötig wäre den Monitor-Inhalt mehr als 10 mal zu enthalten, stellt also alles kein Problem dar.
Das trifft auf den PC zu und Smartphones/Tablets sind auf dem besten Weg auch so viel RAM zu haben. Aber von der Rechenleistung her sollte es doch reichen, dass nicht alles in den RAM muss.
Ich habe heute erst wieder ein Spiel von 1999 in der Hand gehabt und die mind. Anforderungen lesen sich so, dass gerade mal 32MB RAM (unter Windows ab 95) benötigt werden und trotzdem war die Grafik für die damalige Zeit richtig gut.
Heute braucht man auch unter Linux, speziell darauf angepasste Versionen, damit mit so wenig RAM überhaupt ne GUI läuft. (Gut die Auflösungen haben sich auch geändert und das kostet ja auch Speicher, aber trotzdem :P)
-
Hallo,
Das wäre aber nicht mehr effizient. Denn du würdest zeichnen ohne das es Sinn macht. Wieso z.B. den Speicherbus mit einer GIF-Animation belasten, obwohl das Fenster nicht zu sehen ist und das für vllt ein paar Minuten?
Deswegen ja das :Das eine Anwendung wissen können sollte ob ihr Fenster überhaupt sichtbar ist ist aber auch wieder richtig. Sie könnte der GUI ja sagen das sie benachrichtigt werden möchte wenn ihr Fenster wieder sichtbar ist (selbst wenn nur zum Teil), ....
Ich würde das so implementieren das die GUI der Anwendung mit dem Return-Wert einer Zeichen-Aktion immer mitteilt ob das gezeichnete überhaupt komplett oder nur zum Teil und gar nicht sichtbar ist (bei gar nicht eventuell noch nach Grund unterteilt: Verdeckt, Minimiert, Monitor-Aus, usw). Dann kann die Anwendung entscheiden ob es ihr wichtiger ist das sofort ein aktuelles Bild verfügbar ist wenn das Fenster wieder sichtbar wird oder ob lieber CPU-Leistung und Energie gespart werden sollen. Zusätzlich sollte die Anwendung der GUI auch mitteilen können über welche Veränderungen bei der Sichtbarkeit ihrer Fenster sie per Event (über den gleichen Mechanismus wie Tastendrücke und Maus-Events) benachrichtigt werden möchte, dann könnte die Anwendung wieder mit einer GIF-Animation weiter machen wenn der entsprechende Bereich wieder sichtbar ist.
Grüße
Erik
-
Ich würde das so implementieren das die GUI der Anwendung mit dem Return-Wert einer Zeichen-Aktion immer mitteilt ob das gezeichnete überhaupt komplett oder nur zum Teil und gar nicht sichtbar ist (bei gar nicht eventuell noch nach Grund unterteilt: Verdeckt, Minimiert, Monitor-Aus, usw). Dann kann die Anwendung entscheiden ob es ihr wichtiger ist das sofort ein aktuelles Bild verfügbar ist wenn das Fenster wieder sichtbar wird oder ob lieber CPU-Leistung und Energie gespart werden sollen. Zusätzlich sollte die Anwendung der GUI auch mitteilen können über welche Veränderungen bei der Sichtbarkeit ihrer Fenster sie per Event (über den gleichen Mechanismus wie Tastendrücke und Maus-Events) benachrichtigt werden möchte, dann könnte die Anwendung wieder mit einer GIF-Animation weiter machen wenn der entsprechende Bereich wieder sichtbar ist.
Wieso muss sich die Anwendung um sowas kümmern? Das hat die GUI zu erledigen. Die Anwendung zeichnet neu wenn sie dazu aufgefordert wurde (was die Anwendung auch selbst tun kann).
Zumal willst du wirklich das eine Anwendung die Laufzeit deines Laptops beeinflusst, nur weil der Programmierer der Meinung war, das es so richtig wäre. Denn diese Methode heißt ja auch, dass die Anwendung das alle ignorieren kann (der Einfachheit wegen und weil es auf den meisten (allen?) anderen System auch so ist) und dann ist nix mehr mit Strom sparen.
Ich würde schon wollen das die GUI bestimmt, wer zeichnen darf und wer nicht.
-
Hallo,
Ich würde schon wollen das die GUI bestimmt, wer zeichnen darf und wer nicht.
Hm, interessante Meinung, vor allem im Hinblick auf diese Aussage :(was die Anwendung auch selbst tun kann).
Ich denke mal ein GUI wird immer beide Wege anbieten müssen. Mein Vorschlag unterscheidet sich nur etwas in der Umsetzung aber die grundsätzlichen Möglichkeiten sind genauso vorhanden wie in allen anderen GUI-Systemen auch. Die GUI wird die Anwendung üblicherweise nur bei externen Events oder Veränderungen in der Sichtbarkeit (was auch externe Events sind) antriggern neu zu zeichnen, das kann mein Vorschlaug auch indem der Anwendung einfach gesagt wird "Dein Fenster ist sichtbar, male das mal neu" und die Anwendung kann das sofort, nachher oder auch gar nicht tun (je nach Lust und Laune), mir ist dabei nur wichtig das die GUI ansich noch voll funktioniert und nicht blockiert o.ä. Ebenso muss es auch immer eine Möglichkeit geben das die Anwendung von sich aus neu zeichnet, sonst wären Animationen oder z.B. Fortschrittsbalken gar nicht möglich. Das einzigste was ich anders machen möchte ist das bei mir die zweite Variante der Standard-Fall ist. Bei Animationen o.ä., also den Dingen wo die Anwendung von sich aus regelmäßig neu zeichnet, sollte die Anwendung eh Dinge wie die Sichtbarkeit des Fensters berücksichtigen um eben nicht unnütz Energie zu verschwenden, das muss die Anwendung aber in beiden Varianten auf jeweils ähnliche Weise tun.
Ich sehe nicht wo meine Idee schlechter sein sollte als der übliche Weg. Ich bin eher der Meinung das meine Idee mehr Flexibilität bringt weil die GUI unabhängiger ist (was leider u.a. mit einem deutlich höherem Speicherverbrauch einhergeht aber damit kann ich gut leben).
Die einzigste Möglichkeit die ich sehe Animationen u.ä. mit absolut maximaler Effizienz (im Bezug auf Energie-Verbrauch und auf CPU-Zeit-Verbrauch) zu ermöglichen ist wenn die GUI die Animationen gleich selber erledigt. Man könnte ja der GUI einfach sagen "ich hab da eine Pane und in die legst Du mir Bitte dieses GIF rein und lässt das ab dem Zeitpunkt X laufen", dann hätte die GUI volle Kontrolle darüber und bräuchte auch nicht die Anwendung wenn das Fenster wieder sichtbar wird oder sowas. Mit Videos könnte man ähnlich verfahren und dann wäre die GUI-Library in der Anwendung nur noch ein dünner Wrapper für die GUI-API. Der große Nachteil dieser Variante ist das dadurch die GUI selber sehr groß und Feature-Reich wird und dann trotzdem nicht für absolut alle Fälle die passende Logik enthält.
Ich denke bei einer Anwendung die von sich aus zeichnen muss muss der Programmierer sich eh Gedanken über Effizienz und Energieverbrauch machen, da kommt der einfach nicht drumherum, egal was für Konzepte die GUI benutzt.
Grüße
Erik
-
So wie ich mir das vorstelle, muss die Anwendung aber nichts darüber wissen ob das Fenster sichtbar ist und in welchem Bereich.
Das die Anwendung auch selbst sagen kann das sie neuzeichnen will heißt nicht das sie das auch macht, das wiederrum entscheidet die GUI.
Sagen wir mal nen Fenster besteht aus nem Message-Port über den es Nachrichten (Events) empfängt. Die einzige Aufgabe dieses Fensters (und des Message-Handlers), ist es auf Events entsprechend zu reagieren. Z.B. wird bei einem Redraw-Event (wo auch der Bereich, der gezeichnet werden soll mit drin ist) wird halt neu gezeichnet und nur dann!
Hat das Fenster jetzt eine Animation, dann schickt jedes Mal wenn eine Änderung nötig ist, eine Nachricht an die GUI (meinet wegen nen Want-Redraw Event) und die GUI entscheidet ob das überhaupt nötig ist (zwecks Sichtbarkeit und sowas). Ist es nötig, wird nen Redraw-Event an das Fenster geschickt, ansonsten nicht.
Die Anwendung selber sollte nach dem MVC Prinzip aufgebaut sein, sprich das Modell ändert sich zwar ständig, aber die View wird nur aktualisiert wenn nötig.
Das Modell kann ja gerne pro GIF Bild schon nen Buffer haben und die View würde diesen nur noch in den entsprechenden Bereich kopieren, aber ob das passiert entscheidet die GUI.
Denn ich als fauler Programmierer (und sind wir nicht alle faul ;) ) würde mich nicht dafür interessieren (und ich möchte meinen dass das unter Windows und auch Java so ist) ob mein Fenster jetzt sichtbar ist und wo, sondern ich zeichne halt immer mit dem Bereich den ich bekomme neu (entsprechend meines Modells).
Du verlangst also vom Programmierer das er sich noch um Dinge kümmern muss, was eigentlich gar nicht sein müsste.
Ich denke bei einer Anwendung die von sich aus zeichnen muss muss der Programmierer sich eh Gedanken über Effizienz und Energieverbrauch machen, da kommt der einfach nicht drumherum, egal was für Konzepte die GUI benutzt.
Ich wünschte es wäre so, aber seien wir doch mal ehrlich. Der PC ist dafür bekannt, dass man alle Probleme mit schnelleren CPUs und mehr RAM erschlägt. Wirkliche Effizienz wird auf der PC Platform nicht groß geschrieben.
Sowas siehst du auf Embedded Systemen und Konsolen. Dort wo die Ressourcen halt stark begrenzt sind.
Edit::
Wo wir gerade bei viel RAM sind. Da du es ja auch so machen willst, das pro Nachricht ein neuer Thread gestartet wird, könnte man sogar folgendes probieren.
Alle Nachrichten die nix mit dem neuzeichnen zu tun haben werden an nen extra Port geschickt und dort läuft dann das Modell. Das Modell hat immer einen Snapshot des aktuellen Zustands der in einem Pointer gespeichert wird (und halt vor nem Zugriff geschützt werden muss, dazu später mehr). Jedes Mal wenn sich was ändern soll, werden die Sachen halt geändert und es wird ein neuer Snapshot erstellt. Dieser muss gegen den vorhandenen (das würde sogar mit nem einfachen xchg gehen und wäre somit atomisch ohne das man den Pointer irgendwie schützen müsste :D) ausgetauscht werden. Sollte der alte Snapshot noch vorhanden sein sprich der Pointer ist ungleich null, kann der Snapshot wieder freigegeben werden.
Im Thread vom Fenster (der Port der nur fürs Zeichnen zuständig ist) macht im Endeffekt das gleiche, er holt sich den vorhanden Pointer und tauscht ihn mit null aus. Es wird dann dem Snapshot entsprechend gezeichnet und der Snapshot kann dann freigegeben werden.
Damit hätte man wunderbar Multithreading eingesetzt und hätte beides voneinander getrennt. Ich bin mir gerade nicht sicher ob 2 Snapshots ausreichen würden (mehr dürften eigentlich nicht nötig sein oder?), aber die könnte man ja fest vor allozieren und damit würde das ganze schnell genug (??) sein.
Allerdings würde ich noch mind. einen dritten Thread verwenden. Nämlich einen der CPU intensive Sachen macht, so dass die GUI immer benutztbar ist, auch wenn die Anwendung gerade rechnet (was z.B. ja bei den meisten Packprogrammen gut funktioniert). Wie genau dieser Thread nötig ist, weiß ich im Moment selber nicht, aber das dürfte sich dann beim Programmieren ergeben.
Meine Frage wäre aber, ist solch eine Aufteilung mit den bekannten Libs (Qt und sowas) überhaupt möglich?
-
Hallo,
Gut, dann sage doch mal was nen modernen Desktop modern macht (du denkst dabei doch an bestimmte Features oder?).
Ja, ich denke an Compositing und Overlays. Das sind beides Dinge, die man mit einem VESA-artigen Treiber nur unter Schmerzen oder mit einem vollständig anderen Codepfad unterstützen kann.
Auf meine Frage ob das Linux mit seinen Framebuffer-Devices nicht auch macht, hast du leider nicht geantwortet.
Ja, weil Framebuffer Devices eine völlig andere Baustelle sind. Das hängt damit zusammen, dass auf nicht-x86 kein allgemeiner Standard für Textausgabe existiert und Linux daher eine solche API brauchte. Es gibt Framebuffer-Treiber mit Video- und 2D-Beschleunigung (letzteres z.B. der sonst kaputte viafb). Was du eigentlich meinst, ist etwas komplexeres (vgl. KMS), wobei KMS aus Kompatiblitätsgründen die fbdev-API bereitstellt. Das ist in meinen Augen alles historisches Kompatiblitätsgeraffel und mit einem modernem Desktop (Compositing) nicht vereinbar.
also mir persönlich gefällt das Konzept wo die Anwendung dazu aufgefordert wird Teile oder alles ihrer Fenster neu zu zeichnen absolut gar nicht.
Naja, wenn ich ein Fenster verschiebe, dann muss das Fenster, was da vorher (teilweise) hinter gelegen hat, davon erfahren und den Teil, der gerade freigelegt wurde, neu zeichnen.
Nö, in meiner (sicherlich naiven) Vorstellung ist auch das verdeckte (oder verkleinerte) Fenster in der GUI immer komplett vorhanden (ja ich weiß dass das Speicher kostet) und kann daher sofort ohne mitwirken der Applikation dargestellt werden.
Das ist richtig, bei Compositing ist das auch so. Allerdings kann man - wenn man die Anwendung zum Neuzeichnen auffordern kann - die eigentlichen Buffer auch wegwerfen, wenn der Speicher knapp ist. Die Buffer gehören nur in den Video-RAM, wenn die Grafikkarte das Compositing in Hardware machen kann, sonst sollte man das in den System-RAM tun.
Ich hab mir X11 vor etlichen Jahren nur mal kurz und nur recht oberflächlich angesehen. Vom Konzept her ist das wimre gar nicht mal so verkehrt wenn wohl auch die Umsetzung nicht mehr so ganz Zeitgemäß ist.
Ich kenne nur den Begriff "over-engineered". Einfach viel zu kompliziert und zu sehr auf die 80er-Jahre-Technologien zugeschnitten; inzwischen also total veraltet und größtenteils in den Bibliotheken neu und moderner implementiert. Deswegen ja auch der Ansatz, alles von der Anwendung machen zu lassen. :-)
GTK und Qt machen eigentlich alles in SW und liefern an die GUI nur noch ein fertiges Bitmap, genau das finde ich persönlich eher ungeschickt und von der Performance her auch suboptimal.
Finde ich weniger, denn auch GTK und Qt nutzen Backend-Libraries (z.B. OpenGL oder Cairo), die durchaus hardwarebeschleunigt sein können. Ich bin der Meinung, eine GUI sollte sich weniger um die Innereien der Anwendungen kümmern müssen.
Ich behaupte mal mit einer passenden HW-Unterstützung und der Fähigkeit von der Grafik-Library diese Möglichkeiten auch durch das GUI-System hindurch effizient nutzen zu können sollte man einen schicken und modernen KDE-Desktop auch mit nem 100 MHz Pentium noch flüssig bedienbar machen können.
Das bezweifle ich. Klar kann man mit Spezialchips die CPU entlasten, aber zu der Zeit steckte da nicht mehr drin als ein Framebuffer mit Blitting und 4 MB VRAM. Compositing geht da einfach nicht sinnvoll.
Gut, auch wieder wahr, den Svenska zu ignorieren wäre einfach unhöflich.
lol :P
Stell Dir einfach mal ein animiertes GIF vor (um z.B. eine kleine Fortschrittsanimation anzuzeigen), da könnte doch die Anwendung sich immer per Event antriggern lassen
Das betrachte ich als vom Design her kaputt.
Ich glaube da hast Du mich missverstanden. Ich meine das die Anwendung sich z.B. von einem System-Timer regelmäßig antriggern lassen kann, ...
Achso, aber das hat ja mit der GUI nichts zu tun. Dass die Anwendung z.B. einen Timer-Tick jede Sekunde bekommt und ein Bildfenster (GIF-Element) neu zeichnen lässt, ist ja ne System-Sache; sie muss den Button ja auch neuzeichnen, wenn da grad einer mit der Maus draufklickt (oder drüberfährt).
Für richtige Videos sollte natürlich auch ne spezial-API vorhanden sein, obwohl ich schon der Meinung bin das das grundsätzlich auch ohne spezial-API möglich sein sollte solange die RAM-Performance und auch die PCI-Performance dabei gut mitspielen (was heute selbst für Full-HD als gegeben zu betrachten ist).
Wenn der Videodekoder intern mit einem YUV-Farbformat arbeitet (eigentlich immer), und die Grafikkarte direkt YUV malen kann, dann sollte man das nutzen können, besonders weil das bereits eine Komprimierung sein kann. (YUYV = 4 Byte für 2 Pixel, RGB = 3-4 Byte pro Pixel). Interessant wird es dann, wenn du Videos nebenbei laufen lässt und die GUI trotzdem nutzen möchtest.
Für ein einfaches Vollbildvideo kann man das natürlich auch in Software pinseln, aber das verschwendet Rechenzeit und damit Strom. ;-)
Scrollen würde ich persönlich ganz anders machen. Ich würde das komplette Bild in den Video-Speicher laden und der Grafikkarte nur noch sagen "da liegt ein Bild mit den Ausmaßen X:Y an Offset Z im Video-RAM, zeichne davon den Teilausschnitt von U:V mit H:W ins Frame an A:B". Wenn gescrollt wird muss dann immer nur U:V angepasst werden und fertig.
Stimme ich zu, allerdings ist das wiederum Aufgabe der Anwendung, das so zu implementieren. Je nach Fall ist das nämlich nicht möglich (wenn z.B. für jeden Scrollvorgang eine Datenbank befragt werden muss und die gesamte Datenbank zu groß ist). Die GUI selbst fordert von der Anwendung ja eigentlich nur den vorgerenderten Buffer und zeichnet ihn.
Das wäre aber nicht mehr effizient. Denn du würdest zeichnen ohne das es Sinn macht. Wieso z.B. den Speicherbus mit einer GIF-Animation belasten, obwohl das Fenster nicht zu sehen ist und das für vllt ein paar Minuten?
Weil es einerseits nicht weh tut, du aber andererseits jederzeit eine aktuelle Vorschau des Fensters anfordern kannst (vgl. die Win7-Taskleiste).
Wenn ich mir überlege, was das auch an CPU Leistung kosten würde, wenn alle meine Tabs ständig am zeichnen wären bzw was sich da einsparen lässt.
Andere Baustelle: Das Tab-Steuerelement weiß, welches Tab sichtbar ist und kann die Redraw-Ereignisse der untergeordneten Fenster weglassen bzw. das Neuzeichnen unterlassen. Ansonsten vermute ich, dass das neuzeichnen gemacht wird (eine Flash-Animation im Hintergrund kostet ordentlich CPU).
Anderes Bsp wäre wenn der Bildschirm aus wäre oder der Bildschirmschoner an wäre, da würden bei dir die Anwendungen alle schön weiterzeichnen. Auch ein blinkender Cursor muss nicht ständig aktualisiert werden, wenn das Fenster eh nicht zu sehen ist.
Der Cursor folgt dem Fokus, ist also immer im Vordergrund. ;-) Du kannst ja ein Ereignis definieren, was das Neuzeichnen unterbindet.
Das trifft auf den PC zu und Smartphones/Tablets sind auf dem besten Weg auch so viel RAM zu haben. Aber von der Rechenleistung her sollte es doch reichen, dass nicht alles in den RAM muss.
Dann musst du auf Compositing usw. komplett verzichten und dich mit den damaligen Technologien zufriedengeben. Das sehe ich bei der GUI etwas anders als sonst, weil da einfach die Möglichkeiten extrem gestiegen sind und ich das nicht als Bloat betrachte.
Ich habe heute erst wieder ein Spiel von 1999 in der Hand gehabt und die mind. Anforderungen lesen sich so, dass gerade mal 32MB RAM (unter Windows ab 95) benötigt werden und trotzdem war die Grafik für die damalige Zeit richtig gut.
Du hast das schon richtig formuliert: Für die damalige Zeit. Nicht für die heutige Zeit. Eine Oberfläche im Win95-Look lässt sich nicht mehr verkaufen und ein paar Dinge, die Compositing bietet, finde ich toll.
Ich würde das so implementieren das die GUI der Anwendung mit dem Return-Wert einer Zeichen-Aktion immer mitteilt ob das gezeichnete überhaupt komplett oder nur zum Teil und gar nicht sichtbar ist (bei gar nicht eventuell noch nach Grund unterteilt: Verdeckt, Minimiert, Monitor-Aus, usw).
Naja, ich würde der Anwendung einfach ein Ereignis schicken, was ihr mitteilt, dass sie vorerst nicht automatisch neuzeichnen muss. Bei normalen Anwendungsfenstern möchte man ja schon gerne ein aktuelles Vorschaubild haben, bei einem Browsertab im Hintergrund sieht man es ohnehin nicht (und wenn, kann man ja ein normales RedrawNow-Ereignis hinschicken).
Wieso muss sich die Anwendung um sowas kümmern? Das hat die GUI zu erledigen. Die Anwendung zeichnet neu wenn sie dazu aufgefordert wurde (was die Anwendung auch selbst tun kann).
Die Anwendung zeichnet neu, wenn sie dazu aufgefordert wurde oder wenn sie es für richtig hält. Ein Ereignis "du bist jetzt nicht sichtbar" und "du bist jetzt wieder sichtbar" reicht da aus, um ihr diese Entscheidung zu ermöglichen.
Die GUI hat sich darum nicht zu kümmern, weil das Anwendungsinterna sind. Entweder, die Anwendung kümmert sich um sich selbst oder sie muss von der GUI wie ein Baby behandelt werden.
Zumal willst du wirklich das eine Anwendung die Laufzeit deines Laptops beeinflusst, nur weil der Programmierer der Meinung war, das es so richtig wäre. Denn diese Methode heißt ja auch, dass die Anwendung das alle ignorieren kann (der Einfachheit wegen und weil es auf den meisten (allen?) anderen System auch so ist) und dann ist nix mehr mit Strom sparen.
Ja, genau das möchte ich. Der Programmierer kann nämlich auch Threads mit einer Endlosschleife im Hintergrund erzeugen und dann bringt das ebenfalls nichts. Wenn ich den Anwendungen nicht ein bisschen vertrauen kann, brauche ich keinen Computer mehr. Da stimme ich Erik vollkommen zu.
So wie ich mir das vorstelle, muss die Anwendung aber nichts darüber wissen ob das Fenster sichtbar ist und in welchem Bereich.
Nein, aber du musst diese Information der Anwendung ja nicht gezielt vorenthalten. Für normale Fenster ist das wirklich total unwichtig, für manche Steuerelemente (wie z.B. Tab-Container) ist das wieder relevant.
Hat das Fenster jetzt eine Animation, dann schickt jedes Mal wenn eine Änderung nötig ist, eine Nachricht an die GUI (meinet wegen nen Want-Redraw Event) und die GUI entscheidet ob das überhaupt nötig ist (zwecks Sichtbarkeit und sowas). Ist es nötig, wird nen Redraw-Event an das Fenster geschickt, ansonsten nicht.
Würde ich eher über einen Zustand im Fenster lösen, also das übergeordnete Fenster sagt dem Steuerelement "du bist gerade unsichtbar" und das Steuerelement schickt an das übergeordnete Fenster halt keine "Want Redraw Event"-Events mehr.
Ich finde übrigens folgende Herangehensweise sinnvoller:
- GUI schickt Fenster ein Redraw-Event, das Fenster zeichnet sich neu und antwortet mit einem "RedrawDone"-Event.
- Das Fenster findet, dass es sich neu zeichnen muss, tut das und sendet ein "RedrawDone"-Event.
Warum muss die GUI jedes Fenster antriggern/takten, damit der Bildschirm schicker aussieht? Man kann das zwar mit der Bildwiederholrate synchronisieren, aber wann triggert man eigentlich, wenn zwei Bildschirme mit unterschiedlichen Frequenzen angesteuert werden? (Da jedes Fenster einen eigenen Buffer hat, kann man es auch auf beiden Bildschirmen haben...) Daher sollte die GUI das Fenster nur bei bestimmten Ereignissen antriggern, nicht per Timer.
Denn ich als fauler Programmierer (und sind wir nicht alle faul ;) ) würde mich nicht dafür interessieren (und ich möchte meinen dass das unter Windows und auch Java so ist) ob mein Fenster jetzt sichtbar ist und wo, sondern ich zeichne halt immer mit dem Bereich den ich bekomme neu (entsprechend meines Modells).
Du verlangst also vom Programmierer das er sich noch um Dinge kümmern muss, was eigentlich gar nicht sein müsste.
Vom Toolkit-Programmierer, ja. Nicht vom Anwendungsprogrammierer. Jedes Steuerelement muss selbst wissen, wie es auf bestimmte Ereignisse reagiert.
Wirkliche Effizienz wird auf der PC Platform nicht groß geschrieben.
Sowas siehst du auf Embedded Systemen und Konsolen. Dort wo die Ressourcen halt stark begrenzt sind.
Richtig. Dort hast du aber auch keine modernen Desktops.
Und Hand aufs Herz - um wieviel % CPU-Zeit geht es denn bei deiner kleinen GIF-Animation? Wenn du einen 486er mit ISA-Grafikkarte optimal ausreizen willst, dann hast du eben kein Compositing und keine Live-Vorschau der Fenster. Punkt. Das geht nicht. Willst du beides optimal unterstützen, hast du zwei komplett getrennte Codepfade, für ein Hobby-OS zuviel Aufwand. Dann bau lieber deinen VESA-Treiber so, dass er Buffer-Management, Compositing usw. im System-RAM durchführt und eine gerade so akzeptable Fähigkeitenliste simuliert.
FlashBurn: Das mit den Ports und dem IPC sind Implementierungsdetails, die ich ziemlich komplex finde. Eine single-threaded Anwendung blockt halt, während sie ein Ereignis verarbeitet, daran lässt sich nichts ändern. Multithreading vorzuschreiben halte ich für unsinnig, außerdem wird das Toolkit das ohnehin schon tun, wenn das für sinnvoll erachtet. Dein Vorschlag definiert genau, wie eine Anwendung intern zu funktionieren hat und das ist in meinen Augen ein Designfehler.
Gewöhn dich daran, dass andere Programmierer anders denken und erschwere ihren Stil nicht über das Notwendige hinaus. Du bist kein Jurist, der alles Unerwünschte verbieten muss.
Gruß,
Svenska
-
Ja, ich denke an Compositing und Overlays. Das sind beides Dinge, die man mit einem VESA-artigen Treiber nur unter Schmerzen oder mit einem vollständig anderen Codepfad unterstützen kann.
Ist Compositing wirklich so schwer mit nem VESA-Treiber umzusetzen? Weil es wird in erster Linie ja "nur" der Speicherbus belastet und wenn man dann den fertigen Frame zusammenstellt, reicht es ja nur die nötigen Bereiche zu kopieren, oder übersehe ich da was?
Es gibt Framebuffer-Treiber mit Video- und 2D-Beschleunigung
Ich dache bei Framebuffer-Devices immer daran, dass man nur den Framebuffer der Graka nutzen kann, wenn z.B. kein richtiger Treiber vorhanden ist (wie oft im Embedded/Smartphone/Tablet Bereich). Ich wusste nicht dass da sogar 2D-Beschleunigung (in welcher Form eigentlich?) mit dabei ist.
Weil es einerseits nicht weh tut, du aber andererseits jederzeit eine aktuelle Vorschau des Fensters anfordern kannst
Das würde ich auch wieder so implementieren, das dann wenn eine Vorschau nötig ist, diese erst angefordert wird. So wird das mMn auch unter Windows gemacht, denn unter Bestimmten Bedingungen musst du ein Fenster erst wieder in den Vordergrund bringen, damit das mit der Vorschau wieder funktioniert.
Andere Baustelle: Das Tab-Steuerelement weiß, welches Tab sichtbar ist und kann die Redraw-Ereignisse der untergeordneten Fenster weglassen bzw. das Neuzeichnen unterlassen. Ansonsten vermute ich, dass das neuzeichnen gemacht wird (eine Flash-Animation im Hintergrund kostet ordentlich CPU).
Wenn die Anwendung das intern (Modell) in einem Buffer machen möchte, kann sie das ja auch tun. Es ist ja nicht so, dass es bei meinem Design unmöglich ist. Das wäre dann auch in Richtung Compositing in der Anwendung.
Der Snapshot würde dann immer aus einem Buffer mit dem Bildinhalt bestehen und bei nem Redraw-Event wird nur noch dieser Buffer genommen und an die GUI geschickt.
Der Cursor folgt dem Fokus, ist also immer im Vordergrund.
Ich meinten nen Cursor in einer Konsole.
Du hast das schon richtig formuliert: Für die damalige Zeit. Nicht für die heutige Zeit. Eine Oberfläche im Win95-Look lässt sich nicht mehr verkaufen und ein paar Dinge, die Compositing bietet, finde ich toll.
Keine Frage, Compositing bietet schon ein paar tolle Sachen, auf die ich auch ungern verzichten möchte, aber ich gebe mich zumindest für mein OS (irgendwo muss ich ja Abstriche machen ;) ) auch mit nem Win95 (eigentlich sogar Win3.11, weil ich mit Grafik noch nicht viel zu tun hatte) Look zu frieden. Ich finde das ganze extreme bunte (seit XP) und mit sonst was für Spielerein versehene auch nicht wirklich gut. Mir würde ne GUI wie sie bei BeOS/Haiku gibt, vollkommen ausreichen.
Nein, aber du musst diese Information der Anwendung ja nicht gezielt vorenthalten. Für normale Fenster ist das wirklich total unwichtig, für manche Steuerelemente (wie z.B. Tab-Container) ist das wieder relevant.
Wieso ist das für manche Steuerelemente wichtig (ich kenne mich da halt gar nicht aus)?
Warum muss die GUI jedes Fenster antriggern/takten, damit der Bildschirm schicker aussieht? Man kann das zwar mit der Bildwiederholrate synchronisieren, aber wann triggert man eigentlich, wenn zwei Bildschirme mit unterschiedlichen Frequenzen angesteuert werden? (Da jedes Fenster einen eigenen Buffer hat, kann man es auch auf beiden Bildschirmen haben...) Daher sollte die GUI das Fenster nur bei bestimmten Ereignissen antriggern, nicht per Timer.
Da komme ich jetzt irgendwie nicht mit?! Wer redet denn davon das die GUI die Fenster per Timer antriggert? Ich will ja das die GUI die Fenster zu bei bestimmten Ereignissen antriggert.
Richtig. Dort hast du aber auch keine modernen Desktops.
Was sind Smartphones und Tablets denn für dich? Für mich steckt da immernoch embedded Hardware drin (gut die so ca. auf nem Stand von x86 vor 10 Jahren ist, was die CPU betrifft).
Wenn du einen 486er mit ISA-Grafikkarte optimal ausreizen willst, dann hast du eben kein Compositing und keine Live-Vorschau der Fenster. Punkt.
Stimme ich dir voll und ganz zu. Das müsste man dann halt abschalten können (das geht ja unter Windows mit den Features auch bis zu einem gewissen Punkt).
Eine single-threaded Anwendung blockt halt, während sie ein Ereignis verarbeitet, daran lässt sich nichts ändern. Multithreading vorzuschreiben halte ich für unsinnig, außerdem wird das Toolkit das ohnehin schon tun, wenn das für sinnvoll erachtet. Dein Vorschlag definiert genau, wie eine Anwendung intern zu funktionieren hat und das ist in meinen Augen ein Designfehler.
Mit der Aussage habe ich so meine Probleme. Denn was ist denn das was x86 und auch Windows oft vorgeworfen wird? Die Kompatibilität! Wieso also "alte" Sachen zulassen, wenn es vielleicht neuere (die dann vielleicht schwieriger umzusetzen sind) bessere Wege gibt?
Darum geht es doch eigentlich auch irgendwo bei einem Hobby-OS. Ansonsten würde erik keine eigene Architektur mit einem OS das bei einigen (vielen?) Sachen mit der "normalen" Welt bricht.
Es wird durch ein Interface doch eh vorgeschrieben wie man eine GUI programmiert und von daher sehe ich das als nicht so schlimm an. Zumal man sehr viel davon auch in den Toolkits verstecken kann und auch sollte.
Allerdings finde ich halt die "Einstellung" das wurde schon immer so gemacht und deswegen müssen wir es weiterhin so machen ein wenig (mindestens ;) ) falsch.
-
Hallo,
So wie ich mir das vorstelle, muss die Anwendung aber nichts darüber wissen ob das Fenster sichtbar ist und in welchem Bereich.
Das ist in meinen Augen eine zu starke Einschränkung. Ich denke bei den meisten Anwendungen kommen die meisten Redraw-Events von der Anwendung selber (weil sich die darzustellenden Daten geändert haben) und nicht von der GUI (Fenster verschoben o.ä.). In der Hinsicht ist auch diesen Bitten der Anwendung an die GUI einen Redraw anzufordern meiner Meinung nach eher Quatsch, die GUI macht doch dafür auch nur ein 'if (sichtbar)' und das kann auch in der GUI-Library innerhalb der Anwendung passieren, dazu ist keine IPC-Kommunikation erforderlich. Wenn z.B. in Qt jedes QWidges genau weiß ob es sichtbar ist oder nicht kann die Anwendung einfach ins Root-QWidget einen Redraw-Event einspeisen und jedes QWidget das sichtbar ist (wenn auch nur zum Teil) zeichnet neu und fordert dann alle seine unter QWidget's auf das auch zu tun, bei einem QWidget das nur teilweise sichtbar ist wird es eventuell Unter-QWidget's geben die gar nicht sichtbar sind so das diese nichts zeichnen und auch nicht ihre internen Unter-QWidget's zum neuzeichnen auffordern. Für eine Fenster-Vorschau (die ja nur relativ selten passiert) könnte die GUI dann ja einen Redraw-All-Event an die Anwendung schicken bei dem die Sichtbarkeit in allen QWidget's immer ignoriert wird. Das einzigste was man dazu bräuchte wäre eine effiziente Methode allen QWidget's präzise mitzuteilen ob sie sichtbar sind oder nicht und da würde sich IMHO der Return-Wert von der GUI nach einem Zeichenbefehl anbieten.
Hat das Fenster jetzt eine Animation, dann schickt jedes Mal wenn eine Änderung nötig ist, eine Nachricht an die GUI (meinet wegen nen Want-Redraw Event) und die GUI entscheidet ob das überhaupt nötig ist (zwecks Sichtbarkeit und sowas). Ist es nötig, wird nen Redraw-Event an das Fenster geschickt, ansonsten nicht.
Fürchterlich umständlich. Es geht um ein einfaches 'if (sichtbar)' und dafür 2 IPC-Vorgänge, Du findest doch sicher auch dass das ein bisschen daneben ist oder?
Das Modell kann ja gerne pro GIF Bild schon nen Buffer haben und die View würde diesen nur noch in den entsprechenden Bereich kopieren, aber ob das passiert entscheidet die GUI.
Also bei einer GIF-Animation würde ich das anders lösen. Die Anwendung gibt der GUI alle Bilder und sagt dann später nur noch welches Bild jeweils in dem vorgesehenen Rechteck dargestellt werden muss. Wenn das Fenster im Vordergrund ist sollten auch alle Bilder in den Video-RAM übertragen werden und die GUI muss nur noch im Frame-Descriptor in der Grafikkarte einen Pointer ändern, das ist dann effizient. Wenn das Fenster nicht im Vordergrund ist ändert die GUI nur in der internen Fenster-Repräsentation einen Pointer und wäre zumindest immer sofort in der Lage eine Vorschau zu liefern oder das Fenster in den Vordergrund zu bringen ohne das die Anwendung erst neu zeichnen muss. Der CPU-Aufwand pro Bildwechsel wäre dafür so minimal das es unerheblich ist ob das Fenster nun sichtbar ist oder nicht. Was mich an Deiner Beschreibung am meisten stört ist das Wort "kopieren". Kopieren ist für eine CPU der blödeste Job überhaupt, da ist die CPU voll beschäftigt und der Speicherbus voll ausgelastet und trotzdem hat keine einzige der CPU-Internen Recheneinheiten etwas sinnvolles zu tun. Gerade dieses Kopieren ist es was heutige GUIs so CPU-Intensiv macht, das möchte ich anders machen, in meiner GUI soll möglichst nie kopiert werden müssen (mit einem halbwegs modernen Grafikkontroller der jünger als 10 Jahre ist ist das auch nicht erforderlich, Grafikkarten können seit gut 10 Jahren Compositing in HW und ausreichend Video-RAM ist auch seit vielen Jahren vorhanden).
Denn ich als fauler Programmierer (und sind wir nicht alle faul ;) )
Bitte schließe nicht von Dich auf andere. Ein Programmierer der sich nicht wenigstens ein bisschen für die Effizienz seiner Programme interessiert ist meiner persönlichen Meinung nach kein echter Programmierer (das heißt nicht das der Programmierer Nächte lang auch noch den letzten Takt an Effizienz raus quetschen muss aber wenigstens grundlegende Effizienz-Paradigmen sollte er berücksichtigen). Mit solchen Individuen (von denen es sicher einige gibt) möchte ich nicht auf eine Stufe gestellt werden.
Du verlangst also vom Programmierer das er sich noch um Dinge kümmern muss, was eigentlich gar nicht sein müsste.
Ich verlange von einem Programmierer das es sich zumindest etwas bemüht und das er sich mit dem was er da programmiert zumindest rudimentär auskennt. Sollte das jemand nicht schaffen so möchte ich seine Programme auch nicht auf meiner Plattform haben. Punkt! Die Programme derartig desinteressierter Programmierer dürften auch sonst nicht viel taugen.
Wirkliche Effizienz wird auf der PC Platform nicht groß geschrieben.
Das liegt aber auch oft nicht an den Programmierern selber sondern an deren Umfeld (Arbeitgeber usw.), das sollte bei einem Hobby-OS anders sein.
Meine Frage wäre aber, ist solch eine Aufteilung mit den bekannten Libs (Qt und sowas) überhaupt möglich?
Vielleicht nicht perfekt aber ganz bestimmt irgendwie, es würde mir sehr schwer fallen zu glauben das so generische Libraries wie Qt da unnötig einschränken.
Allerdings kann man - wenn man die Anwendung zum Neuzeichnen auffordern kann - die eigentlichen Buffer auch wegwerfen, wenn der Speicher knapp ist. Die Buffer gehören nur in den Video-RAM, wenn die Grafikkarte das Compositing in Hardware machen kann, sonst sollte man das in den System-RAM tun.
Ganz recht, in meiner Fantasie ist die GUI einer der wenigen Kandidaten (neben dem VFS mit seinem Cache) wo es sich lohnt das der Kernel bei Speicherknappheit mal anfragt ob man nicht ein wenig Speicher freigeben könnte. Wenn der Rechner total unter Druck ist dann wird der User es auch sicherlich verschmerzen können wenn ein Fenster mal einen Moment braucht bis es wieder was sinnvolles anzeigt, wenn der User es aus der Versenkung holt. Bei einem unterforderten System hat der User aber IMHO durchaus das Recht eine sofort reagierende GUI zu erwarten. Wenn ich eine fette Simulation laufen lasse die alle CPU-Leistung und allen Speicher benötigt dann dauert es eben etwas Zeit bis das Fenster der Office-Anwendung wieder benutzbar ist wenn ich es frisch in den Vordergrund hole (das wird mir schon die Festplatten-LED signalisieren), wenn sich mein Computer aber mit ein paar einfachen Webseiten langweilt dann ist es IMHO nicht zu viel verlangt das ein Fensterwechsel sofort erledigt ist. Leider kommt diesem Ideal weder Windows noch KDE auch nur nahe, hier sehe ich oft dass das OpenOffice-Fenster einen kurzen Moment benötigt bis wieder alle Buttons usw. klar sichtbar sind, klar ist dieser Moment recht kurz und ich kann damit gut leben aber in Anbetracht der Möglichkeiten der vorhandenen Hardware ist es einfach nur beschämend dass das nicht besser gehen mag.
Finde ich weniger, denn auch GTK und Qt nutzen Backend-Libraries (z.B. OpenGL oder Cairo), die durchaus hardwarebeschleunigt sein können.
Achso, dann is ja gut. Ich will auch nicht das sich die GUI-Library um die Internas der Anwendung kümmert sondern dass das was die GUI-Library-API anbietet möglichst effizient ausgeführt werden kann und da ist IMHO Hardwarebeschleunigung eine gute Möglichkeit aber die erfordert das schon möglichst früh in der Kette die Aktivität von der Anwendung in die GUI verlagert wird.
Ich behaupte mal mit einer passenden HW-Unterstützung und der Fähigkeit von der Grafik-Library diese Möglichkeiten auch durch das GUI-System hindurch effizient nutzen zu können sollte man einen schicken und modernen KDE-Desktop auch mit nem 100 MHz Pentium noch flüssig bedienbar machen können.
Das bezweifle ich. Klar kann man mit Spezialchips die CPU entlasten, aber zu der Zeit steckte da nicht mehr drin als ein Framebuffer mit Blitting und 4 MB VRAM. Compositing geht da einfach nicht sinnvoll.
Klar, die Grafikkarten zur Zeit eines Pentium 100 MHz waren nicht der Bringer aber eine Grafikkarte die jünger als 10 Jahre ist (also ausreichend RAM hat und Compositing anständig in HW unterstützt) sollte auch in Kombination mit einem alten Pentium 100 MHz einen gut bedienbaren und modern aussehenden KDE-Desktop ermöglichen.
Interessant wird es dann, wenn du Videos nebenbei laufen lässt und die GUI trotzdem nutzen möchtest.
Ja, ich erwarte absolut selbstverständlich die GUI auch dann noch benutzen zu können wenn in einem Fenster ein Video läuft. Selbst bei zwei Fenstern mit unabhängigen Videos erwarte ich das noch, solange das Decodieren der Videos die CPU nicht ans Limit bringt.
Stimme ich zu, allerdings ist das wiederum Aufgabe der Anwendung, das so zu implementieren.
Naja, wenn es sich wirklich nur um ein statisches Bild handelt (das eben einfach nur seeeehr groß ist) dann sollte sich die GUI-Library darum kümmern können das ordentlich gescrollt werden kann. Wenn die Daten aber wirklich erst von einem anderen System geliefert werden müssen ist das ganz klar etwas komplexer und erfordert in der eigentlichen Anwendung auch entsprechenden Code.
Ein Ereignis "du bist jetzt nicht sichtbar" und "du bist jetzt wieder sichtbar" reicht da aus, um ihr diese Entscheidung zu ermöglichen.
Eben, genau das finde ich auch.
Entweder, die Anwendung kümmert sich um sich selbst oder sie muss von der GUI wie ein Baby behandelt werden.
;)
Mit der Aussage habe ich so meine Probleme. Denn was ist denn das was x86 und auch Windows oft vorgeworfen wird? Die Kompatibilität! Wieso also "alte" Sachen zulassen, wenn es vielleicht neuere (die dann vielleicht schwieriger umzusetzen sind) bessere Wege gibt?
Darum geht es doch eigentlich auch irgendwo bei einem Hobby-OS. Ansonsten würde erik keine eigene Architektur mit einem OS das bei einigen (vielen?) Sachen mit der "normalen" Welt bricht.
Es wird durch ein Interface doch eh vorgeschrieben wie man eine GUI programmiert und von daher sehe ich das als nicht so schlimm an. Zumal man sehr viel davon auch in den Toolkits verstecken kann und auch sollte.
Allerdings finde ich halt die "Einstellung" das wurde schon immer so gemacht und deswegen müssen wir es weiterhin so machen ein wenig (mindestens ;) ) falsch.
Hier muss ich FlashBurn grundsätzlich zustimmen, zu arg an althergebrachtem festzuhalten ist auf jeden Fall der falsche Weg.
Mein IPC-System erzwingt u.a. das alle Anwendungen multithreading-tauglich sind, das trifft in jedem Fall die libc (welche ja auch von mir kommt) die dann threadsave sein muss, der Anwendungsprogrammierer muss sich damit aber nicht zwangsläufig auseinander setzen solange er nicht vor hat komplexere Anwendungen zu bauen die das IPC direkt nutzen. Wenn jemand auf eine Library aufsetzt die multithreading erwartet (z.B. Qt in vielen aber nicht allen Dingen) dann muss er sich auch damit auseinander setzen, wenn aber jemand nur die libc benutzt dann kann er darauf verzichten.
Grüße
Erik
-
In der Hinsicht ist auch diesen Bitten der Anwendung an die GUI einen Redraw anzufordern meiner Meinung nach eher Quatsch, die GUI macht doch dafür auch nur ein 'if (sichtbar)' und das kann auch in der GUI-Library innerhalb der Anwendung passieren, dazu ist keine IPC-Kommunikation erforderlich.
Das würde so wie ich mir es vorstelle nicht klappen. Bei mir müsste sich die Anwendung selbst eine Nachricht schicken. Denn diese Nachricht wird ja in einem anderen Thread ausgeführt und der wird für die Nachricht erstellt und ruft dann den Code auf.
Für eine Fenster-Vorschau (die ja nur relativ selten passiert) könnte die GUI dann ja einen Redraw-All-Event an die Anwendung schicken bei dem die Sichtbarkeit in allen QWidget's immer ignoriert wird. Das einzigste was man dazu bräuchte wäre eine effiziente Methode allen QWidget's präzise mitzuteilen ob sie sichtbar sind oder nicht und da würde sich IMHO der Return-Wert von der GUI nach einem Zeichenbefehl anbieten.
Naja, deswegen ist es ja leichter, wenn die GUI immer das zeichnet was sie als Bereich von der IPC Nachricht bekommt.
Fürchterlich umständlich. Es geht um ein einfaches 'if (sichtbar)' und dafür 2 IPC-Vorgänge, Du findest doch sicher auch dass das ein bisschen daneben ist oder?
Naja, wenn du es so siehst, dann dürften wir nicht an nem MikroKernel schreiben. Weil seien wir ehrlich nen Monolith ist was das betrifft wesentlich effizienter.
Ich finde das so halt "schöner" vom Design her.
Die Anwendung gibt der GUI alle Bilder und sagt dann später nur noch welches Bild jeweils in dem vorgesehenen Rechteck dargestellt werden muss.
Aber würde das nicht heißen das du extra für solche Sachen ein Feature in der GUI haben wirst?
Was mich an Deiner Beschreibung am meisten stört ist das Wort "kopieren". Kopieren ist für eine CPU der blödeste Job überhaupt, da ist die CPU voll beschäftigt und der Speicherbus voll ausgelastet und trotzdem hat keine einzige der CPU-Internen Recheneinheiten etwas sinnvolles zu tun.
Naja, kopieren wäre es halt bei nem einfachen Framebuffer/VESA-Treiber. Bei ner modernen Graka wo man nen Treiber für hat, kann man doch bestimmt der Graka sagen das sie nen bestimmten Speicherbereich aus dem System-RAM holen soll (aber auch da ist der Speicherbus belastet und auch das ist irgendwo kopieren).
Bitte schließe nicht von Dich auf andere.
Naja, was das betrifft, liefer ich sowas "nur" für die Uni ab. Ansonsten geht das leider bei mir soweit, das ich mit vielen Sachen nie fertig werde, weil ich es immernoch verbessern will.
Allerdings werden halt neue Sprachen deswegen "erfunden", weil die meisten Programmierer faul sind und so wenig wie möglich schreiben wollen.
Mit solchen Individuen (von denen es sicher einige gibt) möchte ich nicht auf eine Stufe gestellt werden.
Sorry, war nicht meine Absicht.
Klar, die Grafikkarten zur Zeit eines Pentium 100 MHz waren nicht der Bringer aber eine Grafikkarte die jünger als 10 Jahre ist (also ausreichend RAM hat und Compositing anständig in HW unterstützt) sollte auch in Kombination mit einem alten Pentium 100 MHz einen gut bedienbaren und modern aussehenden KDE-Desktop ermöglichen.
Das dürfte in dem Fall am PCI-Bus scheitern. Ansonsten wäre es wahrscheinlich schon möglich.
Ansonsten kann ich sagen, dass ne moderne GUI (Ubuntu 11.10) auch auf nem Framebuffer-Device (ohne Hardwarebeschleunigung) funktionieren, habe ich selbst im Einsatz. Das einzige was nicht funktioniert sind Videos (weil halt zu viel kopiert werden muss).
-
Hallo,
Ist Compositing wirklich so schwer mit nem VESA-Treiber umzusetzen? Weil es wird in erster Linie ja "nur" der Speicherbus belastet und wenn man dann den fertigen Frame zusammenstellt, reicht es ja nur die nötigen Bereiche zu kopieren, oder übersehe ich da was?
Eigentlich nicht, es wird nur relativ aufwändig zu implementieren. Ich vermute, dass es gute Gründe gibt, bei VESA-only auf Compositing zu verzichten...
Ich dache bei Framebuffer-Devices immer daran, dass man nur den Framebuffer der Graka nutzen kann, wenn z.B. kein richtiger Treiber vorhanden ist (wie oft im Embedded/Smartphone/Tablet Bereich). Ich wusste nicht dass da sogar 2D-Beschleunigung (in welcher Form eigentlich?) mit dabei ist.
Zu einem Framebuffer-Treiber gehört auch mindestens ein Modesetting, oft auch dynamisch ("fbset" ist das Programm dafür). Der Export als /dev/fb* ist nur eine Möglichkeit, darauf zuzugreifen, aber ein fbdev-Treiber kann auch Overlays und Blitting anbieten, genaueres weiß ich aber auch nicht. Die werden über ioctl() auf das fb-Device genutzt.
Das würde ich auch wieder so implementieren, das dann wenn eine Vorschau nötig ist, diese erst angefordert wird.
Ja, z.B. über ein Redraw-Event. Das Fenster muss dafür ja nicht direkt sichtbar sein. Wie gesagt: Wenn das Fenster unsichtbar wird, schickst du ein Event, dass jetzt keine automatischen Redraws mehr nötig sind, und wenn es wieder sichtbar wird das Gegenereignis und ein Redraw-Event, dass die Anwendung auch den aktuellen Zustand malt.
Andere Baustelle: Das Tab-Steuerelement weiß, welches Tab sichtbar ist und kann die Redraw-Ereignisse der untergeordneten Fenster weglassen bzw. das Neuzeichnen unterlassen. Ansonsten vermute ich, dass das neuzeichnen gemacht wird (eine Flash-Animation im Hintergrund kostet ordentlich CPU).
Wenn die Anwendung das intern (Modell) in einem Buffer machen möchte, kann sie das ja auch tun. Es ist ja nicht so, dass es bei meinem Design unmöglich ist. Das wäre dann auch in Richtung Compositing in der Anwendung.
Ne, wieso? Das Tab-Steuerelement ist doch ein "Fenster", also gilt die Fenster-Abstraktion des GUI-Systems. Du hast nicht pro Anwendung einen Buffer, sondern pro Fenster, und das können bei normaler Nutzung auch mehrere Hundert sein (Steuerelemtente implementiert man sinnvollerweise als Fenster...) Deswegen ist das beim VESA-Treiber ja so schwierig umzusetzen, weil du alles im System-RAM vorhalten musst, einmal das fertige Bild und einmal jeden Buffer extra. Das macht es schwierig, die Unterschiede festzustellen und eine weitere Kopie des Bildschirminhalts zum Vergleichen ist unschön.
Der Snapshot würde dann immer aus einem Buffer mit dem Bildinhalt bestehen und bei nem Redraw-Event wird nur noch dieser Buffer genommen und an die GUI geschickt.
Naja, dazwischen würde ich warten, bis die Anwendung fertig gezeichnet hat. ;-)
Der Cursor folgt dem Fokus, ist also immer im Vordergrund.
Ich meinten nen Cursor in einer Konsole.
Ja eben. Da blinkt nichts, wenn das Fenster nicht aktiv ist. ;-)
Keine Frage, Compositing bietet schon ein paar tolle Sachen, auf die ich auch ungern verzichten möchte, aber ich gebe mich zumindest für mein OS (irgendwo muss ich ja Abstriche machen ;) ) auch mit nem Win95 (eigentlich sogar Win3.11, weil ich mit Grafik noch nicht viel zu tun hatte) Look zu frieden.
Dann lass Compositing weg. ;-)
Nein, aber du musst diese Information der Anwendung ja nicht gezielt vorenthalten. Für normale Fenster ist das wirklich total unwichtig, für manche Steuerelemente (wie z.B. Tab-Container) ist das wieder relevant.
Wieso ist das für manche Steuerelemente wichtig (ich kenne mich da halt gar nicht aus)?
Weil manche Steuerelemente z.B. selbst für das Ein- und Ausblenden sorgen und das u.U. auch mit Animationen und anderen rechenintensiven Effekten aufpeppen können. Mehr Freiheit ist da schöner, als alles so festzunageln, wie man es gern hätte. Und in der Erstimplementation wirst du eh die Hälfte vergessen, weil du nicht dran gedacht hast. ;-)
Wer redet denn davon das die GUI die Fenster per Timer antriggert? Ich will ja das die GUI die Fenster zu bei bestimmten Ereignissen antriggert.
Das klang bei dir so, als ob die Anwendung ansagen muss, dass sie jetzt eine GIF mit 10 Bildern pro Sekunde darstellen möchte und dann von der GUI 10x/Sekunde angetriggert wird. Das kann die Anwendung aber auch selbst machen.
Richtig. Dort hast du aber auch keine modernen Desktops.
Was sind Smartphones und Tablets denn für dich? Für mich steckt da immernoch embedded Hardware drin (gut die so ca. auf nem Stand von x86 vor 10 Jahren ist, was die CPU betrifft).
Also Embedded und Embedded sind zwei verschiedene Dinge. Erst sagst du, dass Tablets/Smartphones von der Rechen- und 3D-/Grafikleistung mit PCs vergleichbar sind und dann sagst du, dass du sowas modernes nicht unterstützen willst. Was denn nun?
Moderne Desktops setzen moderne Hardware voraus. Ein S3C24xx mit Framebuffer ist dafür halt ungeeignet, ein OMAP4 mit 3D-Beschleuniger ist dafür sehr geeignet. Mein Navi hat keinen wirklichen Desktop (WinCE halt), ein Android-Tablet schon eher...
Wenn du einen 486er mit ISA-Grafikkarte optimal ausreizen willst, dann hast du eben kein Compositing und keine Live-Vorschau der Fenster. Punkt.
Stimme ich dir voll und ganz zu. Das müsste man dann halt abschalten können (das geht ja unter Windows mit den Features auch bis zu einem gewissen Punkt).
Du willst wirklich zwei getrennte GUI-Systeme bauen, einmal mit und einmal ohne Compositing. Naja, da will ich dich nicht von abhalten.
Eine single-threaded Anwendung blockt halt, während sie ein Ereignis verarbeitet, daran lässt sich nichts ändern. Multithreading vorzuschreiben halte ich für unsinnig, außerdem wird das Toolkit das ohnehin schon tun, wenn das für sinnvoll erachtet. Dein Vorschlag definiert genau, wie eine Anwendung intern zu funktionieren hat und das ist in meinen Augen ein Designfehler.
Mit der Aussage habe ich so meine Probleme. Denn was ist denn das was x86 und auch Windows oft vorgeworfen wird? Die Kompatibilität! Wieso also "alte" Sachen zulassen, wenn es vielleicht neuere (die dann vielleicht schwieriger umzusetzen sind) bessere Wege gibt?
Ich halte überflüssige Komplexität für schlecht. Das hat mit Kompatiblität nur wenig zu tun.
Allerdings finde ich halt die "Einstellung" das wurde schon immer so gemacht und deswegen müssen wir es weiterhin so machen ein wenig (mindestens ;) ) falsch.
Ich finde Single-Threaded trotzdem sinnvoll. Erstmal ist es unglaublich einfach, für extrem viele Anwendungsfälle reicht es auch hin und man erspart sich viele Fehlerquellen. Der High-Performance-Webserver lighttpd basiert beispielsweise auch auf einem Thread und asynchronem I/O. Da man meistens sowieso dynamisch generierte Webseiten verwendet, ist das auch kein Bottleneck (die Rechenzeit, um statische Webseiten auszuliefern, ist gering).
Klar, die Grafikkarten zur Zeit eines Pentium 100 MHz waren nicht der Bringer aber eine Grafikkarte die jünger als 10 Jahre ist (also ausreichend RAM hat und Compositing anständig in HW unterstützt) sollte auch in Kombination mit einem alten Pentium 100 MHz einen gut bedienbaren und modern aussehenden KDE-Desktop ermöglichen.
Das ist ja auch der moderne Ansatz: Jede Form der GUI-Beschleunigung wird in der 3D-Hardware der Grafikkarte ausgeführt. Wenn du also in deinen P100 eine moderene 3D-Grafikkarte steckst (was schon nicht funktioniert...) dann hättest du einen modernen composited Desktop mit Effekten etc. in schnell. Theoretisch.
Naja, wenn es sich wirklich nur um ein statisches Bild handelt (das eben einfach nur seeeehr groß ist) dann sollte sich die GUI-Library darum kümmern können das ordentlich gescrollt werden kann. Wenn die Daten aber wirklich erst von einem anderen System geliefert werden müssen ist das ganz klar etwas komplexer und erfordert in der eigentlichen Anwendung auch entsprechenden Code.
Sehe ich anders. Die Anwendung, die prinzipiell mit großen Bildern konfrontiert sein könnte, weiß das in der Regel vorher und kann sich darum kümmern. Das heißt aber nicht, dass der Programmierer das zu Fuß machen muss, das sollte das Toolkit anbieten. Wenn die GUI mit Bildern der zwei- bis fünffachen Bildschirmauflösung klarkommt und schnell arbeitet, dann reicht das. Es gibt ja auch gute 3D-Grafikkarten mit nur 32 MB Speicher oder so, da passt das Bild eh nicht rein.
In der Hinsicht ist auch diesen Bitten der Anwendung an die GUI einen Redraw anzufordern meiner Meinung nach eher Quatsch, die GUI macht doch dafür auch nur ein 'if (sichtbar)' und das kann auch in der GUI-Library innerhalb der Anwendung passieren, dazu ist keine IPC-Kommunikation erforderlich.
Das würde so wie ich mir es vorstelle nicht klappen. Bei mir müsste sich die Anwendung selbst eine Nachricht schicken. Denn diese Nachricht wird ja in einem anderen Thread ausgeführt und der wird für die Nachricht erstellt und ruft dann den Code auf.
Implementierungsdetail. Wenn das so nicht geht, hast du entweder ein kaputtes Design oder du musst dir eben was anderes einfallen lassen. ;-)
Allerdings werden halt neue Sprachen deswegen "erfunden", weil die meisten Programmierer faul sind und so wenig wie möglich schreiben wollen.
Perl: Write Once, Read Never. Danke, ich verzichte. Die Programmiergeschwindigkeit zu erhöhen macht die Anwendungen nicht unbedingt besser...
Ansonsten kann ich sagen, dass ne moderne GUI (Ubuntu 11.10) auch auf nem Framebuffer-Device (ohne Hardwarebeschleunigung) funktionieren, habe ich selbst im Einsatz. Das einzige was nicht funktioniert sind Videos (weil halt zu viel kopiert werden muss).
Dafür hast du aber kein XRENDER, kein EXA, kein XVideo und insbesondere kein Compositing.
Gruß,
Svenska
-
Du hast nicht pro Anwendung einen Buffer, sondern pro Fenster, und das können bei normaler Nutzung auch mehrere Hundert sein (Steuerelemtente implementiert man sinnvollerweise als Fenster...) Deswegen ist das beim VESA-Treiber ja so schwierig umzusetzen, weil du alles im System-RAM vorhalten musst, einmal das fertige Bild und einmal jeden Buffer extra. Das macht es schwierig, die Unterschiede festzustellen und eine weitere Kopie des Bildschirminhalts zum Vergleichen ist unschön.
Das heißt also dass Compositing schon in der Anwendung stattfindet? Ich dachte das die GUI, die Buffer der Fenster hat und nicht die Anwendung selbst. Die GUI würde dann der Anwendung sagen, in welchen Buffer sie zeichnen soll und damit könnte die Anwendung nicht mehr zw. Compositing und nicht-Compositing unterscheiden. Das war eigentlich mein Gedanke und das würde halt funktionieren ohne das die Anwendung etwas davon weiß/wissen müsste.
Naja, dazwischen würde ich warten, bis die Anwendung fertig gezeichnet hat.
Das wäre ja der Vorteil mit diesem Design, man würde Multithreading richtig nutzen und hätte immer sofort ein Bild ohne das die GUI großartig warten muss.
Ja eben. Da blinkt nichts, wenn das Fenster nicht aktiv ist.
Naja, aber so wie du und erik das so erklären, würde die Anwendung trotzdem immer den blinkenden Cursor zeichnen (es sei denn die Anwendung hätte das implementiert mit dem sichtbar und unsichtbar).
Weil manche Steuerelemente z.B. selbst für das Ein- und Ausblenden sorgen und das u.U. auch mit Animationen und anderen rechenintensiven Effekten aufpeppen können. Mehr Freiheit ist da schöner, als alles so festzunageln, wie man es gern hätte. Und in der Erstimplementation wirst du eh die Hälfte vergessen, weil du nicht dran gedacht hast.
Ich gehe fest davon aus, dass ich die GUI (und wahrscheinlich auch meinen Kernel) mehrmals neu schreiben werde.
Das mit den Effekten ist natürlich war (kannst du mal ein konkretes Bsp. bringen?), aber das müsste doch trotzdem bei mir gehen. Dann kommt halt erst ne Nachricht dass das Fenster jetzt wieder sichtbar ist (am besten an das Modell und nicht die View, obwohl ich mir da gerade nicht sicher bin) und dann ne Nachricht zum Redraw (die ja eh kommen muss).
Erst sagst du, dass Tablets/Smartphones von der Rechen- und 3D-/Grafikleistung mit PCs vergleichbar sind und dann sagst du, dass du sowas modernes nicht unterstützen willst. Was denn nun?
Mir ging es darum, das dort ja auch Compositing zu funktionieren scheint und die Leistung halt noch nicht auf aktuellem x86 Niveau ist.
Was die Unterstützung betrifft, ich würde gerne alles unterstützen, was ich aber meine ist, dass ich nicht alles implementieren kann (alleine schon weil keine Doku vorliegt).
Du willst wirklich zwei getrennte GUI-Systeme bauen, einmal mit und einmal ohne Compositing. Naja, da will ich dich nicht von abhalten.
Naja, vllt habe ich das mit dem Compositing noch immer nicht richtig verstanden (siehe oben). Denn ich habe mir das so vorgestellt, dass der Treiber die Buffer fürs Compositing bereit stellt und die Anwendung da dann reinzeichnet und der VESA-Treiber würde halt anstatt vieler einzelner Buffers immer einen Teil des Framebuffers (obwohl das auch schwierig ist, weil man da ja anders zeichnen müsste, zwecks andere Zeilenlänge und sowas (Farbraum!)).
Wie wird das mit dem Farbraum eigentlich gemacht, muss das die Anwendung wissen oder wandelt der Treiber oder die GUI dann die 32bit/24bit in den jeweiligen Farbraum um?
Perl: Write Once, Read Never. Danke, ich verzichte. Die Programmiergeschwindigkeit zu erhöhen macht die Anwendungen nicht unbedingt besser...
Naja, das könnte man auch über C/C++ sagen (im Vergleich zu Assembler) ;) Desto mehr von der Sprache abstrahiert wird, desto weniger Einfluss hat man auf viele Sachen.
Dafür hast du aber kein XRENDER, kein EXA, kein XVideo und insbesondere kein Compositing.
Wie bekomme ich denn raus, ob Compositing benutzt wird oder nicht?
-
Hallo,
Bei mir müsste sich die Anwendung selbst eine Nachricht schicken. Denn diese Nachricht wird ja in einem anderen Thread ausgeführt und der wird für die Nachricht erstellt und ruft dann den Code auf.
Dann rufst Du Dein "Zeichne-Neu"-System eben per Create-Thread() auf (über ne winzige Stub-Funktion die die Aufrufparameter passend setzt, so wie beim IPC-Receive-Stub ja auch) und schon ist die Sache erledigt, sorry aber Du machst Probleme wo keine sind.
Naja, wenn du es so siehst, dann dürften wir nicht an nem MikroKernel schreiben. Weil seien wir ehrlich nen Monolith ist was das betrifft wesentlich effizienter.
Bitte schließe nicht von Dir auf andere! Wenn Du denkst das Dein Micro-Kernel-Design nicht an einen Monolithen heran reicht, okay, aber ich denke über mein Micro-Kernel-Design anders. Ich behaupte Eleganz (im Design und im Code) mit hoher Performance und Effizienz kombinieren zu können. Ob das auch tatsächlich in der Realität klappt muss ich ganz klar erst noch beweisen, das ist mir bewusst, aber ich gehe heute zumindest davon aus das ich das auch hinkriege, sonst würde ich das ganze Projekt erst gar nicht versuchen.
Die Anwendung gibt der GUI alle Bilder und sagt dann später nur noch welches Bild jeweils in dem vorgesehenen Rechteck dargestellt werden muss.
Aber würde das nicht heißen das du extra für solche Sachen ein Feature in der GUI haben wirst?
Ja, aber ein Feature das ich für extrem nützlich halte und das man an sehr vielen Stellen anwenden kann. Denke da nur mal an gedrückte Buttons oder Maus-Over-Effekte, auch da wäre es sinnvoll alle Varianten schon vorher vorzubereiten und der GUI als fertige Bilder zu übermitteln um dann nur noch auszuwählen welches Bild man in dem entsprechenden Widget haben will. Die einzigste Komplexität ist im Speichermanagement für den Video-RAM (die GUI muss sich überlegen welche Bilder da alles rein sollen, bevorzugt von Fenstern die gerade sichtbar sind) und ein kleiner Plausibilitätstest beim Wechseln des Bildes (das neue muss natürlich auch die richtige Auflösung usw. haben) und beim Killen des Fensters müssen auch alle zugehörigen Bilder aus der GUI entfernt werden.
Bei ner modernen Graka wo man nen Treiber für hat, kann man doch bestimmt der Graka sagen das sie nen bestimmten Speicherbereich aus dem System-RAM holen soll
Ja, und man kann dabei auch gleich noch eine Farbraum-Konvertierung durchführen lassen, so das die Grafikkarte intern alles mit 32Bit-RGBA benutzt und die Anwendung aber trotzdem ein 256 Farben-Bild mit Palette der GUI übergeben kann oder auch YUV. Das alles geht dann ohne zusätzliche CPU-Last und genau das ist das Ziel.
(aber auch da ist der Speicherbus belastet und auch das ist irgendwo kopieren).
Ja schon, aber das CPU-Netzwerk wird trotzdem etwas weniger belastet (außerdem könnte die Grafikkarte die Transferrate künstlich niedrig halten wenn es nicht eilt, oder mehrere unabhängige DMA-Queues für unterschiedliche Prioritäten haben) und Du hast eine CPU mehr für wirklich nützliche Dinge zur Verfügung.
Das dürfte in dem Fall am PCI-Bus scheitern. Ansonsten wäre es wahrscheinlich schon möglich.
Klar kann man eine moderne Grafikkarte nicht in einen PC aus der Zeit des 100 MHz Pentium reinstecken (und selbst wenn würde das nicht zum gewünschten Ergebnis führen), es geht mir einfach nur um die Aussage das für eine moderne GUI (mit allem (un)nötigen Schnick und Schnack) in einem modernen System (inklusive moderner Grafikkarte) nicht mehr als die CPU-Leistung eines 100 MHz Pentium erforderlich sein sollte. Nicht mehr und nicht weniger. Dass das unter aktuellen OSen nicht klappt liegt IMHO an einem schlechten Software-Design und nicht an der Hardware.
Ansonsten kann ich sagen, dass ne moderne GUI (Ubuntu 11.10) auch auf nem Framebuffer-Device (ohne Hardwarebeschleunigung) funktionieren, habe ich selbst im Einsatz. Das einzige was nicht funktioniert sind Videos (weil halt zu viel kopiert werden muss).
Und wie viele Prozente Deiner CPU-Leistung wird für die GUI geopfert? Offensichtlich so viel das es nicht mal für Video reicht. Klar kann auch ein schlechtes Konzept erstmal brauchbar funktionieren aber es bleibt ein schlechtes Konzept.
Naja, wenn es sich wirklich nur um ein statisches Bild handelt (das eben einfach nur seeeehr groß ist) dann sollte sich die GUI-Library darum kümmern können das ordentlich gescrollt werden kann. Wenn die Daten aber wirklich erst von einem anderen System geliefert werden müssen ist das ganz klar etwas komplexer und erfordert in der eigentlichen Anwendung auch entsprechenden Code.
Sehe ich anders. Die Anwendung, die prinzipiell mit großen Bildern konfrontiert sein könnte, weiß das in der Regel vorher und kann sich darum kümmern. Das heißt aber nicht, dass der Programmierer das zu Fuß machen muss, das sollte das Toolkit anbieten. Wenn die GUI mit Bildern der zwei- bis fünffachen Bildschirmauflösung klarkommt und schnell arbeitet, dann reicht das. Es gibt ja auch gute 3D-Grafikkarten mit nur 32 MB Speicher oder so, da passt das Bild eh nicht rein.
Klar funktioniert das nur bis zu einer gewissen Größe nur allein über den Video-RAM, deswegen habe ich ja auch vorgeschlagen das man für wirklich große Bilder (also deutlich mehr als das 4-fache der Bildschirmauflösung) auf jeden Fall kacheln sollte und in den Video-RAM nur die Kacheln lädt die auch momentan gesehen werden können (und eventuell noch die umliegenden Kacheln falls das Fenster wirklich im Vordergrund ist (und auch tatsächlich vom User bedient werden kann) und genügend Video-RAM verfügbar ist). Dass das von der GUI-Library, die direkt in die Anwendung gelinkt wird, passend unterstützt werden muss ist klar. Bei Java-Swing-GUI gibt es da eine JScrollPane die aber leider auch nur den Redraw-Event passen umsetzt und weiter nach unten reicht, schöner wäre es wenn die JScrollPane das gesamte enthaltene Element zeichnen lassen würde und beim Bewegen der Scrollbalken einfach immer nur den passenden Ausschnitt nach oben reichen würde (oder am besten HW-Beschleunigung nutzen tät) anstatt bei jeder Scrollbewegung immer ein beschnittenes Redraw-Event nach unten zu reichen. Die benutze Methode muss natürlich davon abhängig sein wie groß das enthaltene Element ist (aber das weiß die ScrollPane ja auch da ansonsten die Scrollbalken nicht passend skaliert werden könnten). Wenn ich mir im Browser ab und an mal ein paar große Bilder ansehe (und diese auf 1:1-Darstellung umschalte) dann hab ich immer sehr hässliche Effekte wenn ich scrolle, und das obwohl ich den proprietären NVidea-Treiber installiert hab (also eigentlich HW-Unterstützung vorhanden sein sollte, der Video-RAM ist auf jeden Fall ausreichend). Es ist einfach frustrierend zu wissen das der Computer das problemlos könnte aber die Software das einfach nicht nutzt sondern lieber umständlich händisch kopiert. :(
Ich gehe fest davon aus, dass ich die GUI (und wahrscheinlich auch meinen Kernel) mehrmals neu schreiben werde.
Hm, so sehr überzeugt bist Du von Deinen Fähigkeiten? Da würde ich mir dann aber lieber ein anderes Hobby suchen. ;) SCNR
Grüße
Erik
-
Dann rufst Du Dein "Zeichne-Neu"-System eben per Create-Thread() auf (über ne winzige Stub-Funktion die die Aufrufparameter passend setzt, so wie beim IPC-Receive-Stub ja auch) und schon ist die Sache erledigt, sorry aber Du machst Probleme wo keine sind.
Ganz ehrlich wozu soviel aufwand, wenn man sich auch selber ne Nachricht schicken könnte (in den Kernel musst du so oder so) ;)
Wenn Du denkst das Dein Micro-Kernel-Design nicht an einen Monolithen heran reicht, okay, aber ich denke über mein Micro-Kernel-Design anders.
Ich denke das kein Micro-Kernel Design, was alleine Performance betrifft, an einen richtig guten (es muss ja ein fairer Vergleich sein) Monolithen rankommen kann! Denn ein Micro-Kernel braucht für dieselbe Aufgabe wesentlich mehr Kontextwechsel als ein Monolith und das kostet schon was. Wenn man dann noch davon ausgeht, das auf einem nicht Segmentbasierenden System (also alle außer deinem ;)), bei jeder Nachricht irgendwelche Daten kopiert werden müssen (ob das nun die Nutzdaten der Nachricht oder die Adressen der Speicherseiten sind, ist egal), dann ist das nochmal was, was Performance gegenüber nem Monolithen kostet.
Ich mache mir da nix vor, viele Tricks die man verwendet um einen Mikro-Kernel schneller zu machen kann man in irgendeiner Weise bestimmt auch für nen Monolithen einsetzen und schon ist der wieder schneller. Aber ich finde nen Mikro-Kernel einfach eleganter und schöner. Zumal es ja durchaus Bereiche gibt, wo man seine Vorteile (Sicherheit) gerne nutzt und mit den Nachteilen keine Probleme hat.
Performance-technisch ist wahrscheinlich ein Hybrid das beste.
Und wie viele Prozente Deiner CPU-Leistung wird für die GUI geopfert? Offensichtlich so viel das es nicht mal für Video reicht. Klar kann auch ein schlechtes Konzept erstmal brauchbar funktionieren aber es bleibt ein schlechtes Konzept.
Das war halt auch mal ein aktuelles Bsp von einem OS was eindeutig kein Hobby-OS mehr ist und genau mit der Sache zu kämpfen hat mit der alle Hobby-OS zu kämpfen haben, Treiber! Und lieber solch ein System am Laufen haben, als gar kein System (bzw. in dem Fall Android).
Ich mache mir halt nix vor und weiß das ich auf jeden Fall den VESA-Treiber verdammt gut optimieren muss und dann kann ich immernoch sehen, was ich an Treibern von Linux (weil woher auch sonst) portieren kann.
Hm, so sehr überzeugt bist Du von Deinen Fähigkeiten? Da würde ich mir dann aber lieber ein anderes Hobby suchen.
Wie gesagt, ich mache mir nix vor. Ich betrachte Programmieren als aktives Lernen und da entwickelt man sich halt weiter. Zumal ich auch der Meinung bin, dass wenn ich alles ganz genau planen würde, würde ich die nächsten 10 Jahre nur am Design arbeiten, weil ich mich erstmal darum kümmern müsste, was welche Anwendungen so alles nutzen und auch brauchen und das wäre Zeitverschwendung.
Wie Svenska schon richtig sagte, werde ich die hälfte vergessen, ganz einfach weil ich es nicht weiß. Erst wenn ich dann ne Anwendung portiere fällt das auf und muss besser gemacht werden.
Ein Programmierer der von seinen Fähigkeiten so überzeugt ist, dass er denkt das er gleich alles beim ersten Mal richtig macht ist dumm und arogant!
Man kann nicht alles Wissen und die IT-Welt entwickelt sich weiter, was heute noch modern ist, ist morgen schon wieder überholt und das kann man einfach nicht planen.
Wenn dem nicht so wäre, würden keine neuen Algos entwickelt werden und vorallem man bräuchte sie nicht. Denn man macht ja alles gleich beim ersten Mal richtig ;)
Jetzt aber mal zu der Hardwarebeschleunigung und dem Kopieren. Es gibt mMn eine Situation (die immer wichtiger wird auf dem PC und wo es noch nix anderes im Smartphone/Tablet-Bereich, mir jeden falls nicht bekannt, gibt) wo der Graka-Speicher gleich dem Systemspeicher ist und das sind integrierte Grakas. Der einzige Unterschied zw. kopieren von der CPU und kopieren von der Graka ist, das die CPU nebenbei noch was machen könnte (wenn sie den nicht auf den Speicher zugreifen muss, sprich es müsste auch alles im Cache sein). Denn die Graka würde dann den Speicherbus auslasten und desto mehr Kerne man hat desto unbedeutender wird das ganze, da man dann eh irgendwann Schwierigkeiten bekommt alle Kerne auszulasten.
-
Hallo,
Das heißt also dass Compositing schon in der Anwendung stattfindet? Ich dachte das die GUI, die Buffer der Fenster hat und nicht die Anwendung selbst.
Die GUI hat ja auch alle Buffer, aber eine Anwendung hat eben nicht nur 2-3 Fenster (mit jeweils eigenem Buffer), sondern die meisten Steuerelemente haben ebenfalls einen. Die GUI verwaltet nur die Buffer und bastelt sie zu einem Desktop zusammen.
Naja, dazwischen würde ich warten, bis die Anwendung fertig gezeichnet hat.
Das wäre ja der Vorteil mit diesem Design, man würde Multithreading richtig nutzen und hätte immer sofort ein Bild ohne das die GUI großartig warten muss.
Zwischen "ich beginne jetzt mit dem Zeichnen" und "ich habe fertig gezeichnet" vergeht immer Zeit, ob du nun Multithreading nutzt oder nicht...
Ja eben. Da blinkt nichts, wenn das Fenster nicht aktiv ist.
Naja, aber so wie du und erik das so erklären, würde die Anwendung trotzdem immer den blinkenden Cursor zeichnen (es sei denn die Anwendung hätte das implementiert mit dem sichtbar und unsichtbar).
Du vermischst Baustellen. :-) Wenn die Anwendung den Fokus verliert, dann gibt es keinen Cursor mehr. Der ist dann weder sichtbar, noch unsichtbar, noch blinkt er.
Das mit den Effekten ist natürlich war (kannst du mal ein konkretes Bsp. bringen?), aber das müsste doch trotzdem bei mir gehen. Dann kommt halt erst ne Nachricht dass das Fenster jetzt wieder sichtbar ist (am besten an das Modell und nicht die View, obwohl ich mir da gerade nicht sicher bin) und dann ne Nachricht zum Redraw (die ja eh kommen muss).
Bei Steuerelementen, die für einen Redraw sehr lange brauchen können, denke ich an z.B. Oszilloskopdarstellungen, wo jeder Messwert mit den vergangenen Messwerten verrechnet werden muss und das sinnvollerweise ständig passiert, ob das Fenster (Steuerelement) nun sichtbar ist oder nicht. Das Ereignis "du bist grad nicht sichtbar" kann ja dazu führen, dass die Vorberechnungen trotzdem weitergeführt werden.
Ansonsten hab ich keine konkreten Beispiele.
Erst sagst du, dass Tablets/Smartphones von der Rechen- und 3D-/Grafikleistung mit PCs vergleichbar sind und dann sagst du, dass du sowas modernes nicht unterstützen willst. Was denn nun?
Mir ging es darum, das dort ja auch Compositing zu funktionieren scheint und die Leistung halt noch nicht auf aktuellem x86 Niveau ist.
Für gutes Compositing brauchst du keinen Quadcore-Prozessor mit 3 GHz und einer OpenGL 4.2 Grafikkarte. Da reichen auch 600 MHz und ein Grafikchipsatz, der das unterstützt. Gibts den nicht, wird kein Compositing implementiert.
Denn ich habe mir das so vorgestellt, dass der Treiber die Buffer fürs Compositing bereit stellt und die Anwendung da dann reinzeichnet und der VESA-Treiber würde halt anstatt vieler einzelner Buffers immer einen Teil des Framebuffers (obwohl das auch schwierig ist, weil man da ja anders zeichnen müsste, zwecks andere Zeilenlänge und sowas (Farbraum!)).
Das geht nicht. Du müsstest im VESA-Treiber jeden Buffer extra haben und eine Kopie des Framebuffers, in den du die einzelnen Buffer zeichnest. Für genügend RAM ist das möglich, aber eben recht viel Overhead und damit nicht optimal. Was du denkst, ist eher so ein "eine Anwendung, ein Buffer" und dann zeichnest du die direkt in den Framebuffer. Das geht auch, beschränkt aber die Möglichkeiten des Compositings.
Wie wird das mit dem Farbraum eigentlich gemacht, muss das die Anwendung wissen oder wandelt der Treiber oder die GUI dann die 32bit/24bit in den jeweiligen Farbraum um?
Implementierungssache. Sinnvoll ist eine Liste mit Formaten (fourcc), die die GUI/Hardware darstellen kann und die Anwendung muss dann in eins dieser Formate konvertieren.
Dafür hast du aber kein XRENDER, kein EXA, kein XVideo und insbesondere kein Compositing.
Wie bekomme ich denn raus, ob Compositing benutzt wird oder nicht?
Stellst du im Window Manager ein - und siehst eigentlich an den Effekten, ob es aktiv ist oder nicht.
Ja, aber ein Feature das ich für extrem nützlich halte und das man an sehr vielen Stellen anwenden kann. Denke da nur mal an gedrückte Buttons oder Maus-Over-Effekte, auch da wäre es sinnvoll alle Varianten schon vorher vorzubereiten und der GUI als fertige Bilder zu übermitteln um dann nur noch auszuwählen welches Bild man in dem entsprechenden Widget haben will.
In deiner Denkweise mag das stimmen, aber deine Denkweise ist nicht alles. :P Es gibt Qt, GTK und noch ein paar Dutzend weiterer Widget-Bibliotheken, die aus jeweils ein paar hundert Bitmaps bestehen (wenn überhaupt). Präventiv alle möglichen Bilder in den VRAM zu tun ist böse. Außerdem verlierst du die Möglichkeit der gemeinsamen Nutzung.
Klar funktioniert das nur bis zu einer gewissen Größe nur allein über den Video-RAM, deswegen habe ich ja auch vorgeschlagen das man für wirklich große Bilder (also deutlich mehr als das 4-fache der Bildschirmauflösung) auf jeden Fall kacheln sollte und in den Video-RAM nur die Kacheln lädt die auch momentan gesehen werden können (und eventuell noch die umliegenden Kacheln falls das Fenster wirklich im Vordergrund ist (und auch tatsächlich vom User bedient werden kann) und genügend Video-RAM verfügbar ist).
Und dem stimme ich vollkommen zu. Allerdings sehe ich die Pflicht da eher in der Anwendung bzw. im Toolkit, nicht um GUI-System. Bei aktivem Compositing handelt es sich größtenteils um Buffer-Management, wenn du da bei vollem Video-RAM einen 8192*32768 großen Buffer beantragst, dann geht das halt nicht. Damit muss die Anwendung selbst klarkommen.
Gruß,
Svenska
-
Die GUI hat ja auch alle Buffer, aber eine Anwendung hat eben nicht nur 2-3 Fenster (mit jeweils eigenem Buffer), sondern die meisten Steuerelemente haben ebenfalls einen. Die GUI verwaltet nur die Buffer und bastelt sie zu einem Desktop zusammen.
Jetzt bin ich verwirrt. Wo ist welcher Speicher gemappt?
Ich dachte das geht so ähnlich wie, man bekommt nen Redraw von der GUI und bekommt auch gleich nen Buffer mit wo man reinschreiben kann (oder man muss sich diesen Buffer erst von der GUI holen) und wenn man dann fertig ist und das der GUI sagt, dann ist der Buffer auch weg.
Die GUI sagt dann der Graka das sie diesen Buffer in ihren eigenen Speicher laden kann (und das wird für jedes Fenster gemacht).
Auch dachte ich das die Anwendung zwar für jedes Steuerelement nen eignen Buffer hat, aber die GUI bekommt immer nen anderen Buffer "zurück" und die Anwendung kopiert in diesen Buffer aus ihren eigenen Buffern rein.
Zwischen "ich beginne jetzt mit dem Zeichnen" und "ich habe fertig gezeichnet" vergeht immer Zeit, ob du nun Multithreading nutzt oder nicht...
Das ist mir klar, aber so wie ich es vorgeschlagen habe, wäre immer ein Bild vorhanden (muss ja nicht komplett aktuell sein) und man müsste nur den Buffer kopieren/senden ohne das die CPU irgendwas großartig rechnen/zeichnen müsste.
Wenn die Anwendung den Fokus verliert, dann gibt es keinen Cursor mehr. Der ist dann weder sichtbar, noch unsichtbar, noch blinkt er.
Da wäre meine Frage ist, was für eine Animation schwebt dir vor, wo eine Anwendung wissen will ob man sie sieht oder nicht? Denn es macht mehr Sinn das eine Anwendung weiß ob sie gerade den Focus hat und wenn sie wieder bekommt eine Animation zeichnet.
Bei Steuerelementen, die für einen Redraw sehr lange brauchen können, denke ich an z.B. Oszilloskopdarstellungen, wo jeder Messwert mit den vergangenen Messwerten verrechnet werden muss und das sinnvollerweise ständig passiert, ob das Fenster (Steuerelement) nun sichtbar ist oder nicht. Das Ereignis "du bist grad nicht sichtbar" kann ja dazu führen, dass die Vorberechnungen trotzdem weitergeführt werden.
Genau dafür ist doch das MVC Konzept gut. Das Modell rechnet fleißig weiter, aber es wird nix gezeichnet. Denn man braucht ja nur die Werte und die kann man auch im Modell speichern.
Implementierungssache. Sinnvoll ist eine Liste mit Formaten (fourcc), die die GUI/Hardware darstellen kann und die Anwendung muss dann in eins dieser Formate konvertieren.
Hmm, das gefällt mir irgendwie nicht. Wieso muss die Anwendung das wissen? Wurde das so auch unter Windows, Linux und anderen GUIs gemacht?
Mir würde es eher gefallen, das ne Anwendung immer in 24bit (wann braucht man eigentlich mal 32bit sprich den Alphachannel?) zeichnet und die GUI wandelt das dann um oder man müsste das im Toolkit verstecken. Auf jeden Fall so, dass der Programmierer sich darüber keine Gedanken machen muss.
-
Die GUI hat ja auch alle Buffer, aber eine Anwendung hat eben nicht nur 2-3 Fenster (mit jeweils eigenem Buffer), sondern die meisten Steuerelemente haben ebenfalls einen. Die GUI verwaltet nur die Buffer und bastelt sie zu einem Desktop zusammen.
Jetzt bin ich verwirrt. Wo ist welcher Speicher gemappt?
Das ist Sache des Grafiktreibers, bei VESA ziemlich sicher der System-RAM. Moderne Grafikkarten können gebrauchbare Speicherverwaltung und haben teilweise sogar MMUs...
Ich dachte das geht so ähnlich wie, man bekommt nen Redraw von der GUI und bekommt auch gleich nen Buffer mit wo man reinschreiben kann (oder man muss sich diesen Buffer erst von der GUI holen) und wenn man dann fertig ist und das der GUI sagt, dann ist der Buffer auch weg.
Wozu? Dann hast du doch verdammt viel Overhead beim Alloziieren/Dealloziieren von diesen Buffern. Total umständlich und langsam. :-)
Jedes Fenster (also auch die meisten Steuerelemente) haben einen Buffer, wo sie reinmalen. Der wird alloziiert, wenn das Fenster erzeugt wird und freigegeben, wenn das Fenster zerstört wird. Und in diesem Buffer darf rumgemalt werden, soviel und sooft man möchte. Aufgabe des Grafiktreibers ist es dann, diese Buffer entsprechend ihrer Reihenfolge so zusammenzubauen, dass am Ende ein Framebuffer entsteht.
Die GUI sagt dann der Graka das sie diesen Buffer in ihren eigenen Speicher laden kann (und das wird für jedes Fenster gemacht).
Nicht unbedingt. Die Buffer kann (und sollte) man sinnvollerweise direkt im VRAM halten, weil die Hardware das Compositing von dort erledigen kann. Effektiv läuft das darauf hinaus, dass man jedes Fenster (Steuerelement) als Textur betrachtet und dann eine Kamerafahrt über die Flächen macht, nur halt in 2D.
Auch dachte ich das die Anwendung zwar für jedes Steuerelement nen eignen Buffer hat, aber die GUI bekommt immer nen anderen Buffer "zurück" und die Anwendung kopiert in diesen Buffer aus ihren eigenen Buffern rein.
"Kopieren". Das ist böse. :-) Die Anwendung fordert einen Buffer pro Steuerelement an und die GUI zeichnet diese Buffer dann. Ein Steuerelement kann auch mehrere Buffer halten und dann der GUI sagen, welcher der gerade aktive Buffer ist (Double-Buffering vermeidet Tearing).
Der Sinn des ganzen liegt darin, dass die Daten in dem Buffer nicht unbedingt von der CPU kommen müssen, sondern z.B. auch per DMA von einer Spezialhardware (3D-Beschleunigerchip, SLI, ...) kommen können. Bei Embedded-Chips hast du meistens einen relativ simplen Framebuffer (mit wenigen 2D-Beschleunigungsfunktionen), der Modesetting macht und Overlays bietet und dann ein 3D-Teil von PowerVR, was da direkt drin rummalen kann (und nicht dokumentiert ist).
Zwischen "ich beginne jetzt mit dem Zeichnen" und "ich habe fertig gezeichnet" vergeht immer Zeit, ob du nun Multithreading nutzt oder nicht...
Das ist mir klar, aber so wie ich es vorgeschlagen habe, wäre immer ein Bild vorhanden (muss ja nicht komplett aktuell sein) und man müsste nur den Buffer kopieren/senden ohne das die CPU irgendwas großartig rechnen/zeichnen müsste.
Ich möchte gerne das aktuelle Bild sehen und kein veraltetes. Beispiel: Filme und Spiele.
Wenn die Anwendung den Fokus verliert, dann gibt es keinen Cursor mehr. Der ist dann weder sichtbar, noch unsichtbar, noch blinkt er.
Da wäre meine Frage ist, was für eine Animation schwebt dir vor, wo eine Anwendung wissen will ob man sie sieht oder nicht? Denn es macht mehr Sinn das eine Anwendung weiß ob sie gerade den Focus hat und wenn sie wieder bekommt eine Animation zeichnet.
Es gibt nur einen systemweiten Fokus (solange du nur eine Tastatur/Maus unterstützt). Die Sichtbarkeit betrifft aber auch Anwendungen im Hintergrund, z.B. bei 3D-Effekten fürs (automatisierte) Ein-/Ausblenden. Das muss nicht sein, wenn es nicht nötig ist. Praktische Anwendungsfälle hab ich keine, lassen sich aber konstruieren.
Genau dafür ist doch das MVC Konzept gut. Das Modell rechnet fleißig weiter, aber es wird nix gezeichnet. Denn man braucht ja nur die Werte und die kann man auch im Modell speichern.
Ja, aber das sollte das Steuerelement bei mir selbst bestimmen dürfen und nicht von der GUI vorgeschrieben kriegen.
Implementierungssache. Sinnvoll ist eine Liste mit Formaten (fourcc), die die GUI/Hardware darstellen kann und die Anwendung muss dann in eins dieser Formate konvertieren.
Hmm, das gefällt mir irgendwie nicht. Wieso muss die Anwendung das wissen? Wurde das so auch unter Windows, Linux und anderen GUIs gemacht?
Für XVideo gibt es eine Liste mit fourcc-Formaten, die die Hardware nativ unterstützt. Farbraumkonvertierungen machen Treiber nicht, das ist unter Linux verpönt (deswegen gibt es auch die libv4l2, die die ganzen kranken Webcam-Formate konvertieren kann; früher hat das der Treiber gemacht, was je nach Format viel Zeit im Kernel bedeutet und die Echtzeitfähigkeit komplett zerstört). Insbesondere YUV gibt es ja in vielen Geschmacksrichtungen. X11 selbst unterstützt ebenfalls nur eine gewisse Menge an Pixmap-Formaten und Visuals, die Liste gibt es vom Programm "xdpyinfo".
Mir würde es eher gefallen, das ne Anwendung immer in 24bit (wann braucht man eigentlich mal 32bit sprich den Alphachannel?) zeichnet und die GUI wandelt das dann um oder man müsste das im Toolkit verstecken. Auf jeden Fall so, dass der Programmierer sich darüber keine Gedanken machen muss.
Dagegen. Wenn du dich auf 24 Bit Farbtiefe festlegst, nagelst du Anwendungen fest. Der Alpha-Channel wird für Halbtransparenz gebraucht, außerdem kann man das als Chroma-Keying oder für Metadaten benutzen. Inzwischen gibt es auch 30-Bit-Displays, die angesteuert werden könnten und wenn du nur 8 Bit Farbtiefe unterstützt, dann musst du auch keine 24-Bit-Buffer bereithalten, die nur Speicher kosten.
Insbesondere Videosoftware wird mindestens ein bisschen YUV machen wollen, wenn das möglich ist und auch Bildverarbeitungssoftware kann davon profitieren. Daher würde ich den anderen Weg gehen: Die GUI bietet eine Liste mit möglichen Formaten an und die Anwendung kann sich davon eins pro Buffer aussuchen - andere Formate werden nicht unterstützt und müssen von der Anwendung selbst (bzw. dem Toolkit) konvertiert werden.
Gruß,
Svenska
-
Jedes Fenster (also auch die meisten Steuerelemente) haben einen Buffer, wo sie reinmalen. Der wird alloziiert, wenn das Fenster erzeugt wird und freigegeben, wenn das Fenster zerstört wird. Und in diesem Buffer darf rumgemalt werden, soviel und sooft man möchte. Aufgabe des Grafiktreibers ist es dann, diese Buffer entsprechend ihrer Reihenfolge so zusammenzubauen, dass am Ende ein Framebuffer entsteht.
Die Buffer kann (und sollte) man sinnvollerweise direkt im VRAM halten, weil die Hardware das Compositing von dort erledigen kann. Effektiv läuft das darauf hinaus, dass man jedes Fenster (Steuerelement) als Textur betrachtet und dann eine Kamerafahrt über die Flächen macht, nur halt in 2D.
Jetzt verwirrst du mich noch mehr ;)
Wenn die Fenster immer in den selben Buffer schreiben und der im VRAM liegt, dann kann ich mir nur vorstellen, dass entweder alle Buffer an 4KB ausgerichtet sind und der VRAM in die Anwendung gemappt wird oder die Anwendung alloziert immer ihren eigenen Buffer und die Graka holt sich dann immer die Daten aus diesen Buffern in ihren VRAM.
Nur letzteres ermöglicht auch einen zu kleinen VRAM zu haben, aber bedeutet auch das ständig das verpönnte kopieren passiert und das 2x "gezeichnet" wird (eigentlich sogar 3x, aber das letzte Mal ist uninteressant). Denn einmal zeichnet die Anwendung in ihren Buffer und einmal halt die Graka in ihren VRAM (beides Mal wird der Speicherbus belastet).
Das die Anwendung ihre eigenen Buffer hat und sich die Graka dann die Daten aus den Buffern holt, wäre auch mit nem VESA-Treiber möglich.
Ich möchte gerne das aktuelle Bild sehen und kein veraltetes. Beispiel: Filme und Spiele.
Das dürfte bei deinen beiden Bsp kein Problem sein. Die GUI fordert ja nur ein neues Bild an, wenn sich was geändert hat, dass wiederrum weiß sie nur wenn die Anwendung ihr das auch sagt (oder sich die Fenstergröße geändert hat oder der Fokus oder sowas halt) und dann liegt das neue und aktuelle Bild ja vor.
Ja, aber das sollte das Steuerelement bei mir selbst bestimmen dürfen und nicht von der GUI vorgeschrieben kriegen.
Naja, da wären wir halt wieder bei Kompatibilität. Wieso muss ich alte Konzepte unterstützen. Ein anderes Bsp. wäre wenn man komplett asynch-I/O voraussetzt. Sehe ich nix falsches drin. Noch ein Bsp. ist das der Linux-Kernel keine alten APIs (oder auch ABIs) für alte Programme behält.
Daher würde ich den anderen Weg gehen: Die GUI bietet eine Liste mit möglichen Formaten an und die Anwendung kann sich davon eins pro Buffer aussuchen - andere Formate werden nicht unterstützt und müssen von der Anwendung selbst (bzw. dem Toolkit) konvertiert werden.
Das leuchtet mir ein.
Ich würde das dann im Toolkit verstecken wollen. Damit der Anwendungsprogrammierer am besten seinen Farbraum auswählen kann und dieser dann gegebenenfalls in den von der GUI unterstützten umgewandelt wird.
-
Hallo,
Wenn die Fenster immer in den selben Buffer schreiben und der im VRAM liegt, dann kann ich mir nur vorstellen, dass entweder alle Buffer an 4KB ausgerichtet sind und der VRAM in die Anwendung gemappt wird oder die Anwendung alloziert immer ihren eigenen Buffer und die Graka holt sich dann immer die Daten aus diesen Buffern in ihren VRAM.
Niemand hindert dich daran, den VRAM häppchenweise in den Adressraum der Anwendung einzubinden. Zumal jeder Buffer mit seiner Größe explizit beim Grafiktreiber angefordert werden muss. Im Prinzip läuft es darauf hinaus, dass die Grafikkarte Compositing in Hardware machen kann - aber nicht muss. Wenn beim VESA-Treiber ein Buffer angefordert wird, liegt der wahrscheinlich nicht im VRAM...
Nur letzteres ermöglicht auch einen zu kleinen VRAM zu haben, aber bedeutet auch das ständig das verpönnte kopieren passiert und das 2x "gezeichnet" wird (eigentlich sogar 3x, aber das letzte Mal ist uninteressant). Denn einmal zeichnet die Anwendung in ihren Buffer und einmal halt die Graka in ihren VRAM (beides Mal wird der Speicherbus belastet).
Jedes Fenster zeichnet in seinen privaten Buffer. Die GUI nimmt dann jeden dieser Buffer und setzt daraus einen globalen Framebuffer zusammen, der dann auf dem Bildschirm dargestellt wird. (Es kann auch zwei globale Framebuffer geben, wenn man Double Buffering möchte, aber das spielt hier keine Rolle.)
Moderne Hardware vorausgesetzt, belastet das den Speicherbus genau einmal: Alle Buffers liegen im VRAM, das Zusammensetzen macht das GUI-System, indem es innerhalb des VRAMs von der Hardware umkopieren lässt. Das lässt sich bspw. mit der 3D-Engine machen (jedes Fenster ist eine Textur, deren x-/y-/z-Position wird festgelegt und von einer virtuellen Kamera aus betrachtet). In 2D sollte soetwas auch möglich sein, ohne den Inhalt zweimal durch die CPU schicken zu müssen.
Das die Anwendung ihre eigenen Buffer hat und sich die Graka dann die Daten aus den Buffern holt, wäre auch mit nem VESA-Treiber möglich.
Klar: Die Buffer liegen im System-RAM (nicht im VRAM) und das Zusammensetzen des Framebuffers wird komplett in Software erledigt. Das Ergebnis wird dann als Block in den Framebuffer geschoben und dargestellt. Das ist möglich, belastet den Speicherbus aber enorm.
Ja, aber das sollte das Steuerelement bei mir selbst bestimmen dürfen und nicht von der GUI vorgeschrieben kriegen.
Naja, da wären wir halt wieder bei Kompatibilität. Wieso muss ich alte Konzepte unterstützen.
Warum möchtest du sowas wie Character- und Blockdevices unterstützen, wenn es doch alte Konzepte sind? :-)
Es geht nicht darum, alle alten Konzepte wegzuwerfen, denn viele haben sich lange bewährt und funktionieren noch immer. Neue Dinge sind oft schön und moderne Algorithmen und Ideen sind sinnvoll, dennoch machen sie ältere Ansätze selten überflüssig.
Traust du den Anwendungen auf deinem OS nichts zu oder warum musst du sie wie Babies behandeln?
Effektiv schreibst du dem Programmierer vor, wie er seine Software zu stricken hat und wie sie zu funktionieren hat. Ich weiß nicht, was du so denkst, aber wenn ich etwas anders ticke als der Systemprogrammierer und mein Programmierstil gezielt verhindert wird, dann lasse ich das Programmieren für diese Architektur ganz schnell wieder sein. Wenn mir eine Programmiersprache nicht gefällt, dann nutze ich sie nicht.
Ein anderes Bsp. wäre wenn man komplett asynch-I/O voraussetzt.
Wenn ich ein Programm portiere, welches auf blocking I/O basiert, dann werde ich da als erstes Polling einbauen, damit es funktioniert. Sicherlich nicht im Sinne des Erfinders, aber der einfachste Weg zum Ziel. Schon ist ein gut gemeinter Befehl zu einer hässlichen Implementierung mutiert. Alle bösen Dinge dieser Welt entstehen aus gutem Willen.
Noch ein Bsp. ist das der Linux-Kernel keine alten APIs (oder auch ABIs) für alte Programme behält.
Och, der Linux-Kernel ist verdammt kompatibel. Ich hab heute meinen 286er (1 MB RAM) wieder ausgebuddelt und ein Xenix installiert. Linux liest das Dateisystem ("sysv") noch heute.
Bist du Jurist oder warum stehst du so auf verbieten? :-)
Gruß,
Svenska
-
Moderne Hardware vorausgesetzt, belastet das den Speicherbus genau einmal: Alle Buffers liegen im VRAM
Das stimmt halt so nicht ganz, im Moment gehts ja auf x86 Richtung integrierte Graka und deren VRAM ist noch immer der Systemspeicher und damit belastet jede Operation der Graka den Speicherbus. Das gleiche ist auch noch bei embedded Systemen der Fall (so lange es sich um einen SoC handelt, denke ich mal auch wird das so bleiben).
Es geht nicht darum, alle alten Konzepte wegzuwerfen, denn viele haben sich lange bewährt und funktionieren noch immer. Neue Dinge sind oft schön und moderne Algorithmen und Ideen sind sinnvoll, dennoch machen sie ältere Ansätze selten überflüssig.
Es geht in die Richtung, das entweder beim Portieren angepasst werden muss (was bei POSIX-Software schonmal der Fall sein wird und bei Software die auf die Hardware zugreift) oder halt ein Kompatibilitätslayer geschrieben werden muss.
Ich will alte Sachen nicht grundsätzlich ausschließen, aber auch nicht unterstützen. Ist wie das man irgendwann auch für x86 mal sagen muss, jetzt wird ein Schnitt gemacht und es wird nur noch x64 Software funktionieren (meinet wegen noch 32bit Software). Die ganze alte 16bit Software wird dann nicht mehr nativ ausgeführt werden können, aber in einem Emulator ginge das weiterhin.
Och, der Linux-Kernel ist verdammt kompatibel. Ich hab heute meinen 286er (1 MB RAM) wieder ausgebuddelt und ein Xenix installiert. Linux liest das Dateisystem ("sysv") noch heute.
Nur solange der Code auch an neuere Versionen angepasst wird und neu kompiliert wird (gut damals gab es noch nicht die Module die es heute gibt, da war doch noch alles direkt in den Kernel kompiliert?). Userprogramme sollten laufen, da sich das Interface ja nicht geändert hat.
Wayland ist doch ein gutes Bsp., da wird doch auch mit dem X-Server gebrochen. Dieser kann aber weiterhin unter Wayland laufen (aber dann bestimmt mit ein wenig Performanceeinbußen), aber es ist halt nur aus Kompatibilitätsgründen.
Bist du Jurist oder warum stehst du so auf verbieten?
Ich will es nicht verbieten, aber wenn jemand (und ehrlich, wer außer mir sollte das sein ;)) andere Konzepte nutzen will, dann muss er sie halt selbst implementieren. Wie z.B. mingw und cygwin POSIX (insbesondere geht es ja eigentlich nur um fork()) unter Windows nachbilden.
So wie ich mir meinen VFS-Server vorstelle ist z.B. ein read()-Syscall nur über Umwege möglich (klingt aufwendiger als es sein wird), weil ich einen anderen Weg vorsehe.
-
Hallo,
Moderne Hardware vorausgesetzt, belastet das den Speicherbus genau einmal: Alle Buffers liegen im VRAM
Das stimmt halt so nicht ganz, im Moment gehts ja auf x86 Richtung integrierte Graka und deren VRAM ist noch immer der Systemspeicher und damit belastet jede Operation der Graka den Speicherbus.
Das spielt aber nur für den Hardwaredesigner eine Rolle, nicht für denjenigen, der das als Grafikspeicher benutzt. Würde mich übrigens wundern, wenn die Grafikkarte da nicht ein bisschen Bandbreite extra für sich hätte (allein schon der CRTC braucht für die Darstellung exklusiven Zugriff).
Wenn der Hardwareentwickler den Speicherbus hinreichend schnell macht, ist das ja auch kein Problem; außerdem handelt es sich ja um einen komplett getrennten Speicherbereich, auf den man u.U. parallel zugreifen kann.
Ich will alte Sachen nicht grundsätzlich ausschließen, aber auch nicht unterstützen.
Okay. Warum willst du dann so bestimmt für VESA optimieren? :-P
Ich will es nicht verbieten, aber wenn jemand (und ehrlich, wer außer mir sollte das sein ;)) andere Konzepte nutzen will, dann muss er sie halt selbst implementieren.
Also alles über Emulationslayer implementieren lassen. Viel Spaß beim Portieren von Software. ;-)
Gruß,
Svenska
-
Okay. Warum willst du dann so bestimmt für VESA optimieren?
Naja, erstens gehe ich davon aus, dass das der Treiber ist da am meisten verwendet wird und dann habe ich gleich einen optimierten Treiber (Framebuffer) für andere Architekturen.
Also alles über Emulationslayer implementieren lassen. Viel Spaß beim Portieren von Software.
Habe ich ja nicht gesagt, dass ich das mache ;)
Du hast in Windows z.B. kein fork() entweder du portierst deine Software nicht oder du musst dich dem gegebenen Interface anpassen. Das ist überall so, es gibt zwar gewisse Standards, aber die verhindern halt auch wirklich neue Sachen, weil alle versuchen sich an den Standard zu halten obwohl dann nicht mehr ein so effektives Interface möglich ist. Das ist übrigens genau das was du auch mal im Zusammenhang mit den sich ständig ändernden Interfaces im LinuxKernel gesagt hattest (das man da halt einfach auf Kompatibilität verzichtet und alles anpasst, damit es effizienter ist).
-
Hallo,
Ganz ehrlich wozu soviel aufwand, wenn man sich auch selber ne Nachricht schicken könnte (in den Kernel musst du so oder so) ;)
Wie viel Aufwand das Abschicken einer asynchronen Message bei Dir ist kannst natürlich nur Du wissen, in Deinem vorangegangenen Post klang das für mich auf jeden Fall nach etwas höherem Aufwand den Du gerne vermeiden würdest aber im Grunde sollte das gegenüber dem bloßen Erstellen eines neuen Threads kaum ein spürbarer Overhead sein. Sorry wenn ich Dich da irgendwo missverstanden habe. Das Problem ansich ist auf jeden Fall einfach zu lösen, ich sehe da keine nennenswerten Schwierigkeiten.
Ich denke das kein Micro-Kernel Design, was alleine Performance betrifft, an einen richtig guten (es muss ja ein fairer Vergleich sein) Monolithen rankommen kann! Denn ein Micro-Kernel braucht für dieselbe Aufgabe wesentlich mehr Kontextwechsel als ein Monolith und das kostet schon was.
Ein Micro-Kernel wird unter gleichen Bedingungen (also selber Computer und äquivalente SW-Qualität bzw. Optimierungen, auch im User-Land) einen Monolithen natürlich nie überholen aber zumindest auf annähernd gleiche Augenhöhe sollte es der Micro-Kernel schon bringen können, zumindest theoretisch. Damit das aber auch in der Praxis klappt muss auch ganz klar die CPU-Architektur usw. mitspielen, also Kontextwechsel müssen so billig wie irgend möglich sein (was man z.B. mit Schatten-Registern und/oder HW-unterstütztem Kontextwechseln erreichen kann). Eine schnelle Syscall-Implementierung ist hier nur ein Aspekt von vielen. Gerade der Punkt mit den Kontextwechseln ist auch das wo ich ansetzen muss um zu beweisen das ein Micro-Kernel auch in der Praxis einem Monolithen zumindest auf gleicher Augenhöhe begegnen kann und dabei trotzdem mehr Sicherheit zu bieten hat. Ob mir das wirklich gelingt kann ich heute natürlich noch nicht mit Gewissheit sagen aber ich bin optimistisch und werde mir alle Mühe geben.
Wie gesagt, ich mache mir nix vor. Ich betrachte Programmieren als aktives Lernen und da entwickelt man sich halt weiter. Zumal ich auch der Meinung bin, dass wenn ich alles ganz genau planen würde, würde ich die nächsten 10 Jahre nur am Design arbeiten, weil ich mich erstmal darum kümmern müsste, was welche Anwendungen so alles nutzen und auch brauchen und das wäre Zeitverschwendung.
Im Grunde hast Du recht das Programmieren auch immer ständiges dazulernen bedeutet und dieses Lernen auch oft beim programmieren passiert, mach ich ja eigentlich nicht so arg anders. Meine Erfahrung sagt mir aber eineindeutig das eine gute Vorbereitung die Erfolgsaussichten eines Projektes signifikant erhöhen kann. Meiner persönlichen Meinung und Erfahrung nach ist "Learning by Doing" nicht immer ein guter Ansatz. Oft ist es besser sich mit einem Thema erst einmal unabhängig von dem eigentlich zu lösenden Problem zu beschäftigen, der Arzt im OP hat auch jahrelang vorher an Leichen geübt bevor er einen lebenden Menschen operiert und soweit ich weiß machen das selbst erfahrene Ärzte wenn sie eine Operation durchführen sollen die sie noch nie oder nur sehr selten durchgeführt haben das sie sich noch mal ne Leiche bestellen und dort eine spezielle Technik o.ä. üben.
Was ich mich frage ist: Wenn Du davon ausgehst das Du bei Trennung von Planung und Ausführung schon allein 10 Jahre für die Planung benötigst was Denkst Du dann wie viel Zeit die gesamte Durchführung benötigt wenn Du beides parallel betreibst? Der Aufwand für die Planung und vor allem auch fürs Code-Tippen wird ja nicht kleiner nur weil Du beides im Interleaving-Verfahren vermengst, unter der Bedingung das Du in beiden Fällen zum selben Ergebnis kommen möchtest. Der Vorteil des "Learning by Doing" ist natürlich das man an einem fast beliebigen Punkt, wo man erstmal zufrieden ist, einfach aufhören kann, der große Nachteil ist das Du in Summe sehr viel mehr Code tippen musst (bis zum selben Endergebnis). Es tut mir ehrlich Leid aber ich kann bei der "unstrukturierten" Methode absolut keinen zeitlichen Vorteil erkennen, eher das Gegenteil.
Ein Programmierer der von seinen Fähigkeiten so überzeugt ist, dass er denkt das er gleich alles beim ersten Mal richtig macht ist dumm und arogant!
Wenn ich von dem Erfolg eines Projekts nicht überzeugt wäre warum sollte ich dann überhaupt anfangen? Ein wesentlicher Aspekt einer guten Projektplanung ist die Risikoanalyse, das habe ich bei meinem jetzigen Projekt auch gemacht und mir ganz klar notiert wo ich noch Wissenslücken habe (das sind sogar einige) und in meine Etappenliste auch mit aufgenommen wann ich gedenke diese zu schließen (meine Planung ist also alles andere als präzise sondern eher ein abstrakter und grober Fahrplan, nur die nächsten paar Schritte sind deutlich konkreter).
Mir ist bewusst das Optimismus und Selbstsicherheit immer eng bei Dummheit und Arroganz liegen, aber von vornherein zu sagen das ich eh mehrere Anläufe brauche um mein Ziel zu erreichen ist meiner persönlichen Meinung nach etwas zu viel Pessimismus und der ist Kontraproduktiv. Stichwort "selbsterfüllende Prophezeiung", das trifft in beiden Richtungen zu, wenn Du fest an den Erfolg Deines Projektes glaubst und auch eine objektive Analyse ergibt das dieser Glaube berechtigt ist dann erhöht schon das allein die Erfolgswahrscheinlichkeit. Ich hab gerade in meiner Anfangszeit als Programmierer, vor 20 Jahren, einiges komplett in den Sand gesetzt aber dann auch relativ schnell gelernt das ein gutes Projekt-Management genauso wichtig ist wie anständig kommentierter Code. In den letzten 15 Jahren hab ich mir eigentlich keinen echten Griff ins Klo mehr geleistet, sicher habe ich nicht alles "In-Time" oder "In-Budget" erledigt und manchmal musste auch ich Teile noch mal komplett neu entwickeln weil meine erste Planung doch noch Lücken hatte (oder ich das eigentliche Problem noch nicht ganz fassen konnte) aber im Großen und Ganzen bin ich mit meiner heutigen Arbeitsweise sehr zufrieden (und meine Arbeitgeber auch). Ich weiß das hier einige Leute denken das es mir gut tun würde ein für mich wichtiges Projekt so richtig gegen die Wand zu manövrieren um mal wieder auf dem Boden der Tatsachen anzukommen (das muss hier keiner bestätigen ich kann das auch so zwischen den Zeilen mancher Beiträge lesen), mir ist auch klar das mein Kommentar mit dem "anderen Hobby suchen" durchaus reichlich arrogant ist (ich konnte mir das trotzdem nicht verkneifen). Ich werde aber trotz allem auch weiterhin für gutes Projekt-Management eintreten, weil ich ehrlich glaube das dies der bessere Weg ist.
Es gibt aber auch in meinem Leben Dinge die ich komplett ohne jegliche (anständige) Planung in angriff genommen habe. Das wichtigste, und bisher auch größte Projekt in meinem Leben überhaupt, das in diese Kategorie fällt ist mein Kind. Als meine damalige Freundin mir vor über 10 Jahren ihre Schwangerschaft gebeichtet hat brauchte ich zwar eine Weile zum überlegen aber ich bin bis Heute der Meinung das meine Entscheidung, ihr zu sagen das wir das gemeinsam durchstehen und aus diesem noch ungeborenen Leben einen anständigen Menschen machen können, absolut richtig war (auch wenn ich heute diesen Job ganz allein machen muss, was ich damals nicht mit einkalkuliert hatte). Das Leben ist nicht immer planbar, es wäre auch ziemlich schlimm wenn es anders wäre, aber ein SW-Projekt (und dazu gehört auch ein eigenes OS) gehört IMHO immer die Kategorie "planbar". Software ist deterministisch und man kann noch vor der ersten Zeile Code sämtliche Anforderungen die diese Software erfüllen soll klar niederschreiben (beides Dinge die nicht auf Kinder zutreffen).
Man kann nicht alles Wissen und die IT-Welt entwickelt sich weiter, was heute noch modern ist, ist morgen schon wieder überholt und das kann man einfach nicht planen.
Das ist zwar richtig, aber gerade die Anforderungen an einen Micro-Kernel sollten sich nur extrem langsam mit der Zeit ändern. Eigentlich muss ein heutiger Micro-Kernel nichts anderes leisten als einer von vor 30 Jahren, nur die Methoden haben sich extrem gewandelt. Natürlich sind auch neue Konzepte dazu gekommen aber die wesentlichen Grundlagen sind noch immer ziemlich identisch. Manchmal findet auch jemand für ein bekanntes Teilproblem eine neue und bessere Lösung (die auch Wechselwirkungen mit anderen Teilproblemen haben kann), aber wirklich fundamental neue Wege hat auch die IT-Welt nur sehr selten eingeschlagen.
Jetzt aber mal zu der Hardwarebeschleunigung und dem Kopieren....
Bei Grafikkarten die keinen eigenen Speicher haben muss mMn überhaupt nicht kopiert werden, es ist nur wichtig das die immer mit den aktuellen Adressen der SW-Fenster-Buffer arbeitet und das die Speicherbandbreite zum einzigen System-Speicher satt ausreicht um auch bei maximaler Bildwiederholrate und maximaler Monitorauflösung noch genügend Reserven für die CPU(s) bleiben. Bei Grafikkarten mit eigenem Speicher sollte die Entscheidung welcher Fenster-Buffer in den Video-RAM kommt vom Treiber getroffen werden, nur der kennt die Fähigkeiten und Beschränkungen der jeweiligen Hardware. Da sich der Inhalt eines solchen Fenster-Buffer nur relativ selten ändert, in Relation zur Bildwiederholrate am Video-Ausgang der Grafikkarte, ist es auf jeden Fall lohnend wenn die Grafikkarte alle darzustellenden Fenster-Buffer im privaten Video-RAM hat (stell Dir das einfach wie ein Cache vor). In den Fällen wo mit jedem Frame in einem Fenster-Buffer ein anderer Inhalt sein soll, z.B. bei einem Video, bedarf es natürlich zusätzlicher Wege um hier eine deterministische Darstellung (also das jedes Bild auch dann zum Monitor gelangt wenn auch der zugehörige Ton zu den Lautsprechern kommt) zu gewährleisten. Bei Bild und Ton bin ich der Meinung das es das Optimalste wäre jedes Einzelbild bzw. jeden Tonabschnitt mit einem Darstellungszeitstempel versehen zur Hardware zu schicken, so das die Hardware immer schon für die nächsten paar Frames die Daten haben kann und diese ohne Probleme zum richtigen Zeitpunkt zum Monitor bzw. Lautsprecher geschickt werden können, dieses Konzept des großzügigen Pufferns hat sich nicht nur bei CD-Brennern bewährt.
Grüße
Erik
-
Meine Erfahrung sagt mir aber eineindeutig das eine gute Vorbereitung die Erfolgsaussichten eines Projektes signifikant erhöhen kann.
Da stimme ich dir zu. Problem ist aber, das ich die meisten Dinge erst lerne wenn ich sie anwende (ich habs nicht so mit der Theorie, ich muss das immer alles selber praktisch ausprobieren) und da nützt mir die Planung gar nix.
Zumal man sich jetzt streiten könnte, wie weit man planen sollte. Denn eine GUI schon bis ins Detail zu planen ohne das auch nur eine Zeile Code des OS steht, halt ich für falsch.
Viele Sachen sehen in der Theorie sehr gut aus und sind in der Praxis eher schlecht, da hilft dann auch die Planung nicht.
Es tut mir ehrlich Leid aber ich kann bei der "unstrukturierten" Methode absolut keinen zeitlichen Vorteil erkennen, eher das Gegenteil.
Der Punkt ist, dass ich während ich programmiere lerne und dadurch die Zeit für die Planung z.B. einer GUI wesentlich verkürzen kann. Wieso kann man (gerade bei einem Hobby, im Beruf mag es anders sein) nicht beides parallel machen? Es nutzt mir nix wenn ich mir z.B. die Doku zur x86 Architektur durchlese und danach plane, weil ich eigentlich schon programmieren müsste, um den Aufwand abzuschätzen und ob nicht doch ein anderes Desgin besser wäre.
Ich werde aber trotz allem auch weiterhin für gutes Projekt-Management eintreten, weil ich ehrlich glaube das dies der bessere Weg ist.
Ich bin durchaus der Meinung dass PM sehr wichtig ist. Nur mein Problem ist einfach die Motivation und die bekomme ich beim Programmieren und nicht beim Planen (da geht die eher flöten ;)).
Es gibt aber auch in meinem Leben Dinge die ich komplett ohne jegliche (anständige) Planung in angriff genommen habe. Das wichtigste, und bisher auch größte Projekt in meinem Leben überhaupt, das in diese Kategorie fällt ist mein Kind. Als meine damalige Freundin mir vor über 10 Jahren ihre Schwangerschaft gebeichtet hat brauchte ich zwar eine Weile zum überlegen aber ich bin bis Heute der Meinung das meine Entscheidung, ihr zu sagen das wir das gemeinsam durchstehen und aus diesem noch ungeborenen Leben einen anständigen Menschen machen können, absolut richtig war (auch wenn ich heute diesen Job ganz allein machen muss, was ich damals nicht mit einkalkuliert hatte).
Also erstmal ziehe ich meinen (imaginären ;)) Hut vor dir, dass du dein Kind alleine groß ziehst. Ich denke wir Männer werden was sowas betrifft immer vergessen.
Ich habe da (zwecks mangelnder Eigenerfahrung) vllt eine naive Einstellung zu, aber ich könnte kein Kind nicht "annehmen" (ich bin allerdings nicht gegen Abtreibung). Erstens sollte man zu dem was man "verbrochen" (ist hier fehl am Platz) hat stehen und mit den Konzequenzen leben und zweitens auch wenn ein Kind durchaus anstrengend ist (und nicht immer Spaß macht), doch etwas sehr schönes und man wird sich später (zumindest mir würde es so gehen) ständig fragen, was wäre wenn?!
Ich habe aber auch die Meinung das es durchaus Menschen gibt, denen man das Kinderbekommen verbieten sollte! Alleine schon der Kinder wegen. Ich weiß das im Endeffekt niemand so richtig darauf vorbereitet ist, aber man sollte dem Kind doch wenigstens was bieten können (und damit meine ich nicht nur finanziell).
Das Leben ist nicht immer planbar, es wäre auch ziemlich schlimm wenn es anders wäre, aber ein SW-Projekt (und dazu gehört auch ein eigenes OS) gehört IMHO immer die Kategorie "planbar". Software ist deterministisch und man kann noch vor der ersten Zeile Code sämtliche Anforderungen die diese Software erfüllen soll klar niederschreiben (beides Dinge die nicht auf Kinder zutreffen).
Dem muss ich ganz klar wiedersprechen. Software ist halt nich planbar! Alleine die Anzahl der SW-Projekte die scheitern zeigen das. Ich maße mir nicht an, genau festlegen zu können wie lange ich für eine Software brauchen werde. Selbst eine ungefähre Schätzung wird nicht hinkommen. Sicherlich mit der Zeit kommt Erfahrung und es wird wahrscheinlich immer genauer, aber es gibt zuviele Sachen die du halt nicht planen kannst. Ein Bsp. können Hardware- oder Treiberprobleme/-fehler seien.
Das ist zwar richtig, aber gerade die Anforderungen an einen Micro-Kernel sollten sich nur extrem langsam mit der Zeit ändern. Eigentlich muss ein heutiger Micro-Kernel nichts anderes leisten als einer von vor 30 Jahren
Ich denke mal, damals hätte man den (besonders auf x86 bezogen) noch nicht mit SMP und Multithreading designt. Genauso solche Sachen wie das NX-Bit oder ASLR, dass sind auch Dinge die in den Kernel müssen.
Mir ging es besonders um andere Ideen (ich habe halt so meine eigenen, aber vllt hat ja jemand anders ne bessere und die will ich dann umsetzen, dass ist halt nicht planbar, wenn man immer das beste will und man wird nie fertig ;)) und das es neue Algos gibt oder neue Hardware.
Als Bsp., ich weiß noch immer nicht wie ich Swapping umsetzen soll und das wird erst (wenn überhaupt) sehr spät (wenn das System schon läuft) implementiert und dafür muss der Kernel auch wieder geändert werden und bis dahin hat sich mein Stil wahrscheinlich auch weiterentwickelt und ich werde in die Versuchung kommen vieles neu zu schreiben (bzw. umzuschreiben). Auch asynch-I/O ist so eine Sache die ich noch nicht verstanden habe und nicht wüsste wie ich es implementieren sollte.
Das ist ja das eigentliche Problem bei einem OS, eigentlich müsste man Erfahrung in allen Bereichen haben und das geht halt in meinem Alter noch nicht so richtig ;) Und ohne diese Erfahrung kannst du das dann auch nicht planen (schon gar nicht vernünftig).
-
Es heißt ja nicht umsonst "do it twice". Einmal ein Wegwerf-Prototyp, an dem man sieht, wo eigentlich die Probleme stecken und was man lösen muss, und dann erst plant man das richtige Projekt. In der Praxis macht das natürlich niemand, weil Projekte grundsätzlich vorgestern fertig sein müssen und dann wird der Wegwerf-Prototyp eben zum Endprodukt. Das ist auch der Grund, warum ich schon Patches abgelehnt habe, die zwar funktionieren, aber eigentlich auf der falschen Ebene arbeiten und deswegen zwar einfacher sind, aber nur einen Spezialfall lösen. Wenn man sie nehmen würde, würde sich niemand mehr drum kümmern, die richtige Lösung zu implementieren. Bei einem Hobby-Projekt ist sowas wahrscheinlich eher weniger ein Problem, da kann höchstens die Motivation für die richtige Lösung ein bisschen drunter leiden, wenn der Hack gut genug funktioniert. Aber grundsätzlich kann ich mir es bei sowas eher vorstellen, einfach alles zweimal zu machen (und andere hier sind ja mittlerweile bei kernel5...)
Ah, und dann gibt es natürlich noch den Second System Effect, also am besten macht man wohl alles dreimal. ;)
-
Ich weiß inzwischen schon gar nicht mehr beim wie vielten Kernel ich bin ;)
Allerdings ist es die 3. Sprache (von Assembler zu C zu C++). In C hatte ich nur einen Kernel und der C++ Kernel ist mehr oder weniger nur ein Port (mit einigen neuen und besseren Sachen).
-
Hallo FlashBurn,
Ich glaube Du hast einen falschen Eindruck von meiner Planung. Es gibt bei mir keinen festen Zeitplan o.ä. (okay im Beruf fragt mein Chef immer schon vorher wie lange ich etwa brauchen werde und diese Fragen kann ich oft nur aufgrund meiner Erfahrung überhaupt so einigermaßen beantworten), meine Planung ist vielmehr eine grobe Etappenliste in der ich mir überlege was ich an welcher Stelle (und nicht zu welchem konkreten Zeitpunkt) machen will, dabei sind die Punkte die noch in weiter Ferne liegen auch noch am wenigsten konkret und werden hin und wieder auch mal komplett geändert. Wirklich konkret ausgeplant ist eigentlich nur der Schritt den ich gerade durchführe und eventuell die nächsten paar Schritte falls diese in unmittelbarem Zusammenhang stehen. Trotzdem betrachte ich diese Art der Planung durchaus als strukturiert, ich habe für alle (so hoffe ich zumindest) wesentlichen Punkte zumindest ein grobe Vorplanung (was die Durchführung und die Ziele betrifft, aber nicht bezüglich des Zeitaufwandes). Gerade was den Zeitaufwand betrifft fällt es auch mir oft recht schwer da vernünftige Voraussagen zu treffen (zumindest bei Dingen die mehr als ein oder zwei Wochen benötigen) und gerade bei einem Hobby-Projekt ist das auch absolut überflüssig, keiner von uns kann sein Privatleben wirklich im voraus planen so das schon allein mein verfügbares Zeitbudget höchstens für die nächsten paar Wochen einigermaßen bekannt ist. Gerade ich in meiner jetzigen Lebenssituation kann eigentlich gar nichts darüber sagen wie viel Arbeit ich an meinem Projekt in naher und mittlerer Zukunft einbringen kann. Ich bin mir relativ sicher das ich selbst dieses Weihnachten noch nicht mal so weit sein werde wie ich eigentlich letztes Weihnachten schon sein wollte (nach meiner letzten Wunschvorstellung von Sommer 2010, seit dem habe ich auch keine weitere Zeitplanung mehr gemacht weil mein Leben die derzeit eh über den Haufen werfen würde).
Natürlich ist es auch falsch Dinge wie eine GUI schon konkret zu Planen noch bevor die erforderliche Basis überhaupt halbwegs funktioniert, aber zumindest ein paar grobe Anforderungen und Vorstellungen kann man schon mal niederschreiben. Dann diskutiert man mal mit jemand über das eine oder andere und sammelt nebenbei auch ein paar neue Erfahrungen und so ändert man dann ab und an auch mal diese groben Anforderungen und Vorstellungen. Wichtig ist das wenn man sich einem Teilschritt so weit angenähert hat das er als nächstes dran kommen muss das man dann auch wirklich weiß was man eigentlich umsetzen will. Es geht bei einer Projektplanung nicht darum jeden winzigen Schritt schon im voraus perfekt definiert zu haben sondern eher darum das man nicht ziellos umher irrt oder Dinge mehrfach angehen muss bis man ein anständiges Ergebnis bekommt.
Mir ist auch klar das Planung ein recht trockenes Geschäft ist aber so ist das Leben nun mal, es gibt in allem hin und wieder mal eine Durststrecke die es zu überwinden gilt. Ich denke das ist eine wesentliche Kernkompetenz die jeder erwachsene Mensch haben muss wenn er in seinem Leben was erreichen will.
Da so viele Software-Projekte schief gehen ist aber oft ein Problem ungenügender und/oder unrealistischer Planung. Es gibt auch ganz klar viele unplanbare externe Einflüsse aber die sollten eigentlich nur den Zeitlichen Aspekt und eher weniger den Inhaltlichen Aspekt der Planung durcheinander bringen, natürlich kann es sich auch mal erst später heraus stellen eine ein geplanter Lösungsweg schlicht unmöglich ist (oder auf das Gesamtprojekt zu negative Konsequenzen hätte) aber das ist gerade der Punkt den eine gute Planung möglichst abfangen sollte.
Zum eigentlichen Thema ist mir noch was wichtiges eingefallen: das (teilweise) Neuzeichnen von Fenster-Buffern sollte möglichst atomar sein also alle Änderungen erst auf einmal wirksam werden wenn das nächste Frame anfängt, ansonsten gibt es hässliche Bildartefakte. Das könnte man z.B. so lösen indem immer ein neuer Fenster-Buffer benutzt wird und auch immer komplett neu gezeichnet wird, solange jedes Widget (also jeder Button usw.) seinen eigenen Buffer hat ist das eine durchaus gute Herangehensweise da die Fenster-Buffer so absolut betrachtet recht klein sind und sich z.B. komplexes Teilemanagement einfach nicht lohnt. Problematisch ist das nur wenn man das Compositing in Software machen muss (was beim simplen VESA-Mode ja zwingenst gegeben ist) da man hier dann sehr viel zu kopieren hat und auch immer das Double-Buffering (besser Tripple-Buffering) in der Grafikkarte nutzen sollte (was bei VESA ja glücklicherweise geht). Wenn man das Compositing in HW erledigen lässt und die Grafikkarte auch alle darzustellenden Fenster-Buffer im lokalen Video-RAM hat kann man aber auch einfach immer im vorhandenen Fenster-Buffer ändern nur ist dann der Fenster-Buffer für den Zeitraum des Übertragens zur Grafikkarte gesperrt was für Anwendungen die sehr oft kleine Teile aktualisieren (z.B. ein Virenscanner der die aktuell gescannte Datei in der GUI angibt) ein Problem wird weil der so blockiert würde. Hier wäre es natürlich von Vorteil wenn die GUI dafür sogt das immer maximal nur ein Redraw-Event an die Anwendung geschickt wird und diese auch entscheidet wann das passiert, auch muss die Anwendung aufpassen das dieses Widget nicht öfters neu gezeichnet wird als überhaupt Bilder zum Monitor kommen, es muss ja keine wertvolle CPU-Leistung für Dinge verschwendet werden die nie zu sehen sind. Im Falle des Virenscanner würde ich das aber lieber so lösen das dieser sich vom System z.B. alle 100 ms antriggern lässt und einen simplen strcmp zwischen den zuletzt dargestellten Dateinamen und dem aktuellen Dateinamen durchführt und nur bei Bedarf der neue Dateiname in ein Pixel-Bild umgewandelt und auch dargestellt wird (ich denke eine Updatefrequenz von 10 Hz und das Auslassen der dazwischen gescannten Dateien ist für einen Virenscanner absolut akzeptabel). In den knapp 100 ms Pause zwischen den Neuzeichenaktionen sollte die Grafikkarte auch immer die Zeit finden den Buffer aus dem System-RAM zu lesen und im Video-RAM neu abzulegen so das immer der selbe Buffer benutzt werden kann.
Das ist auf jeden Fall ein wesentlicher Aspekt der von Anfang an bei der Planung mit berücksichtigt werden muss. ;)
Grüße
Erik
-
Hallo,
Es heißt ja nicht umsonst "do it twice". Einmal ein Wegwerf-Prototyp ....
Ja, auch das ist eine durchaus häufige und auch gar nicht mal so falsche Methode, trotzdem ist es IMHO die Aufgabe einer guten Planung gerade sowas zu vermeiden. Ich denke diese Methode ist ganz gut wenn man etwas macht wovon man noch absolut keine Ahnung hat und daher jegliche Form von Planung sinnlos ist.
.... würde sich niemand mehr drum kümmern, die richtige Lösung zu implementieren. Bei einem Hobby-Projekt ist sowas wahrscheinlich eher weniger ein Problem
Hm, interessante Meinung, wie kommt dann nur das derzeitige IPC-Konzept in tyndur? :evil:
Ich hab jetzt echt überlegt ob ich Dir das schon wieder aufs Brot schmieren sollte aber entschuldige Bitte es ist einfach zu passend zu diesem Thema und Deinem Beitrag, da konnte ich absolut nicht widerstehen.
Ah, und dann gibt es natürlich noch den Second System Effect, also am besten macht man wohl alles dreimal. ;)
Ich habe bis jetzt nur wenige Dinge mehr als zweimal machen müssen aber es stimmt natürlich das es bei einigen Dingen durchaus der Qualität zuträglich ist wenn man noch mal komplett von vorne anfängt.
Grüße
Erik
-
Natürlich ist es auch falsch Dinge wie eine GUI schon konkret zu Planen noch bevor die erforderliche Basis überhaupt halbwegs funktioniert, aber zumindest ein paar grobe Anforderungen und Vorstellungen kann man schon mal niederschreiben. Dann diskutiert man mal mit jemand über das eine oder andere und sammelt nebenbei auch ein paar neue Erfahrungen und so ändert man dann ab und an auch mal diese groben Anforderungen und Vorstellungen. Wichtig ist das wenn man sich einem Teilschritt so weit angenähert hat das er als nächstes dran kommen muss das man dann auch wirklich weiß was man eigentlich umsetzen will. Es geht bei einer Projektplanung nicht darum jeden winzigen Schritt schon im voraus perfekt definiert zu haben sondern eher darum das man nicht ziellos umher irrt oder Dinge mehrfach angehen muss bis man ein anständiges Ergebnis bekommt.
Naja, mal sollte dann zw Planung auf Basis von Erfahrung und Planung mit erstmal lernen worum es geht unterscheiden und letzteres mag ich auf jeden Fall nicht bei meinem Hobby OS machen ;)
Ich will irgendein bestimmtes Feature oder Design in z.B. meiner GUI nutzen, stelle aber fest (wenn ich dann mal zur GUI komme), dass ich dafür noch etwas im Kernel brauche. Dann muss ich den halt ein wenig ändern oder ich stelle hinterher fest das die Performance gar nicht geht und muss doch nochmal nen Rewrite machen. Gerade was die Performance betrifft, ist oft einfach mal die beste Idee ausprobieren als theoretisch durchrechen (dazu gibt es zuviele Faktoren die man berücksichtigen müsste und meist nicht kann) einfach besser.
Nach besser ist, wenn man dann etwas portieren will (oder halt was neues programmiert, ne Anwendung) und feststellt, dass das so ohne weiteres gar nicht möglich ist, weil man an solch einen Fall (da unbekannt) einfach nicht gedacht hat und schon wieder muss man nen Feature hinzufügen und eventuell dadurch Code neuschreiben. Desto "später" (sprich desto mehr schon programmiert ist) desto ärgerlicher und aufwendiger wird es.
Im Falle des Virenscanner würde ich das aber lieber so lösen das dieser sich vom System z.B. alle 100 ms antriggern lässt und einen simplen strcmp zwischen den zuletzt dargestellten Dateinamen und dem aktuellen Dateinamen durchführt und nur bei Bedarf der neue Dateiname in ein Pixel-Bild umgewandelt und auch dargestellt wird (ich denke eine Updatefrequenz von 10 Hz und das Auslassen der dazwischen gescannten Dateien ist für einen Virenscanner absolut akzeptabel). In den knapp 100 ms Pause zwischen den Neuzeichenaktionen sollte die Grafikkarte auch immer die Zeit finden den Buffer aus dem System-RAM zu lesen und im Video-RAM neu abzulegen so das immer der selbe Buffer benutzt werden kann.
Wieso muss sich da die Anwendung drum kümmern und eventuell noch etwas von der Bildwiederholfrequenz wissen und was ist wenn das System so weit ausgelastet ist, dass es das alles gar nicht schafft.
Ich würde es so machen, das man halt den Namen der aktuellen Datei einfach speichert und ne Nachricht schickt das sich was geändert hat (obwohl da wahrscheinlich optimieren könnte) und die GUI entscheidet dann, weil ein neues Bild zusammengestellt wird (zwecks Bildwiederholfrequenz), dass jetzt ein guter Zeitpunkt ist um das Bild anzufordern und sendet der Anwendung ne Nachricht (Redraw()) und diese Zeichnet halt das was aktuell ist.
Das mit der Bildwiederholfrequenz ist z.B. auch ein guter Einwand (da wäre ich nie drauf gekommen und hätte es wahrscheinlich erst durch irgendwelche Fehler oder sowas festgestellt) und da würde ich sogar sagen, dass es mehr Sinn macht, max so oft wie die Bildwiederholfrequenz ist neu zu zeichnen und nicht öfter.
Ich denke diese Methode ist ganz gut wenn man etwas macht wovon man noch absolut keine Ahnung hat und daher jegliche Form von Planung sinnlos ist.
Naja, ich weiß nicht wie viele OS du schon geschrieben hast, aber ich bin immernoch beim ersten ;)
-
Es heißt ja nicht umsonst "do it twice". Einmal ein Wegwerf-Prototyp ....
Ja, auch das ist eine durchaus häufige und auch gar nicht mal so falsche Methode, trotzdem ist es IMHO die Aufgabe einer guten Planung gerade sowas zu vermeiden. Ich denke diese Methode ist ganz gut wenn man etwas macht wovon man noch absolut keine Ahnung hat und daher jegliche Form von Planung sinnlos ist.
Richtig, und genau von solchen Sachen reden wir ja hier. Ich wäre jedenfalls nach den bisherigen Beiträgen hier überrascht, wenn FlashBurn schon fünf GUIs geschrieben hätte und schon genau weiß, wie man es (nicht) angeht.
Wenn du dich damit schon auskennst, dann machst du es ja sowieso gerade mindestens zum zweiten Mal und hast das "do it twice" schon automatisch erfüllt.
Hm, interessante Meinung, wie kommt dann nur das derzeitige IPC-Konzept in tyndur? :evil:
Ich weiß nicht, was für ein Problem du ständig damit hast, aber in tyndur schreiben wir Dinge neu, die kaputt sind. Nur halt nicht alle auf einmal. Und wie das Konzept reingekommen ist? Da war halt kein Projektleiter, der Nein geschrien hat. ;)
Und gerade was IPC angeht, weiß ich noch nicht, durch was für ein Modell ich es ersetzen wollen würde. Spielt im Moment auch keine große Rolle.
-
Hallo,
Ich denke diese Methode ist ganz gut wenn man etwas macht wovon man noch absolut keine Ahnung hat und daher jegliche Form von Planung sinnlos ist.
Richtig, und genau von solchen Sachen reden wir ja hier. Ich wäre jedenfalls nach den bisherigen Beiträgen hier überrascht, wenn FlashBurn schon fünf GUIs geschrieben hätte und schon genau weiß, wie man es (nicht) angeht.
Ich bin nicht der Meinung das wir hier nur von Dingen reden bei denen man keine Ahnung hat bevor man Anfängt. Außerdem kann man die Ahnung auch anders bekommen außer indem man genau das macht was auch das eigentliche Ziel ist. Beim Beispiel der GUI ist es IMHO durchaus denkbar das man das nötige Hintergrundwissen auch dadurch erlangt das man viele unterschiedliche GUI-Programme programmiert und dabei mal verschiedene Techniken aktiv benutzt, auch kann es was nützen wenn man das alles auf mehreren verschiedenen GUI-Implementierungen ausprobiert um einfach mal ein Gefühl dafür zu bekommen welche Umsetzung sich wie am praktischsten benutzen lässt und eine weitere Methode ist simples lernen indem man Bücher ließt, Tutorials durcharbeitet oder sich mit anderen erfahrenen Programmierern unterhält. Ich behaupte mal das man nicht unbedingt bereits eine GUI implementiert haben muss um eine ordentliche GUI implementieren zu können. Genauso muss man nicht zwangsläufig ein OS implementiert haben um ein ordentliches OS implementieren zu können, es reicht wenn man sich das nötige Wissen auf anderem Wege besorgt (man sollte z.B. schon mal Treiber und sonstige systemnahe SW programmiert haben).
Ich weiß nicht, was für ein Problem du ständig damit hast, aber in tyndur schreiben wir Dinge neu, die kaputt sind. Nur halt nicht alle auf einmal. Und wie das Konzept reingekommen ist? Da war halt kein Projektleiter, der Nein geschrien hat. ;)
Naja, das mit tyndur ist aus meiner Sicht so ein hervorragendes Beispiel für :.... "do it twice". Einmal ein Wegwerf-Prototyp, an dem man sieht, wo eigentlich die Probleme stecken und was man lösen muss, und dann erst plant man das richtige Projekt. In der Praxis macht das natürlich niemand, weil Projekte grundsätzlich vorgestern fertig sein müssen und dann wird der Wegwerf-Prototyp eben zum Endprodukt....
Bitte versteh mich nicht falsch, Ihr hab ein funktionierendes OS hinbekommen auf dem sogar eine Reihe an (portierter) SW läuft, das ist eine Leistung auf die Ihr zweifelsohne stolz sein könnt. Trotzdem ist es momentan so das Ihr eher am Fassadenputz arbeitet anstatt mal ein ordentliches Fundament hinzulegen, tyndur macht auf mich eher den Eindruck von sowas (http://www.scheissprojekt.de/hausbau.html).
Und gerade was IPC angeht, weiß ich noch nicht, durch was für ein Modell ich es ersetzen wollen würde. Spielt im Moment auch keine große Rolle.
IPC wurde hier doch nun schon mehr als einmal diskutiert und es ist da eine ziemlich reichhaltige Fülle an Vorschlägen in diesem Forum versteckt, da sollte sich doch auch was passendes für tyndur finden lassen. ;)
Wieso muss sich da die Anwendung drum kümmern und eventuell noch etwas von der Bildwiederholfrequenz wissen und was ist wenn das System so weit ausgelastet ist, dass es das alles gar nicht schafft.
Wo hab ich geschrieben das die Anwendung die Bildwiederholfrequenz kennen muss? Mein Vorschlag war doch ausdrücklich das der Virenscanner mit einer festen Frequenz von 10 Hz die aktuelle Datei ausgibt (sollte diese sich gegenüber der letzten Ausgabe geändert haben). Das mit der Auslastung ist natürlich eine Frage der Priorität, wenn der Event-Handler (der vom System alle 100 ms angestoßen wird) nur mit niedriger Priorität läuft dann ist zumindest gewährleistet das die GUI nicht den Rest blockiert auf der anderen Seite ist das Umwandeln eines Strings in ein Pixel-Bild nicht so aufwendig das dies das System unangemessen belasten würde so das ich persönlich diesen Vorgang lieber mit hoher Priorität laufen lassen würde um als User zumindest immer den aktuellen Fortschritt sehen zu können (mir persönlich ist es recht wichtig zu wissen was die Programme gerade tun, dafür bin ich auch bereit ein halbes Prozent an zusätzlicher Bearbeitungszeit zu akzeptieren). Den meisten Usern ist eine sofort reagierende GUI recht wichtig, selbst dann wenn das System stark ausgelastet ist, von daher bin ich eher der Meinung das man den CPU-Verbrauch der GUI auf ein Minimum reduzieren sollte um sie so ruhigen Gewissens mit hoher Priorität laufen lassen zu können. Die meisten Programme die zeitaufwendige Arbeiten in extra Workerthreads auslagern geben diesen Threads auch eine minimal niedrigere Priorität um zu jedem Zeitpunkt eine reaktionsfähige GUI gewährleisten zu können.
Ich würde es so machen, das man halt den Namen der aktuellen Datei einfach speichert und ne Nachricht schickt das sich was geändert hat (obwohl da wahrscheinlich optimieren könnte) und die GUI entscheidet dann, weil ein neues Bild zusammengestellt wird (zwecks Bildwiederholfrequenz), dass jetzt ein guter Zeitpunkt ist um das Bild anzufordern und sendet der Anwendung ne Nachricht (Redraw()) und diese Zeichnet halt das was aktuell ist.
Das klingt für mich sehr umständlich, außerdem ist es IMHO zweifelhaft das die Anwendung den Redraw auch immer vor dem nächsten Frame fertig bekommt, nicht jedes Display wird mit nur 60 Hz betrieben, auch 100 Hz oder 120 Hz sind durchaus anzutreffen. Nebst dessen das ein Redraw ja wohl immer beim Fenster-Wurzel-Widget eingespeist wird so das der Job erstmal durch alle Unter-Widgets traversieren muss und eventuell noch andere (unkritische) Widgets ebenfalls auf die Idee kommen neu zu zeichnen. Außerdem müsste die GUI von der Grafikkarte einen IRQ bekommen um überhaupt zu wissen wann die Grafikkarte anfängt ein Bild zum Monitor zu übertragen. Ne, ich bleibe bei meiner Einschätzung das Du das irgendwie viel zu umständlich angehst.
Das mit der Bildwiederholfrequenz ist z.B. auch ein guter Einwand (da wäre ich nie drauf gekommen und hätte es wahrscheinlich erst durch irgendwelche Fehler oder sowas festgestellt)
Dann is ja gut das wir hier über diese Dinge diskutieren. Das ist doch auch eine Art Lernprozess, oder?
und da würde ich sogar sagen, dass es mehr Sinn macht, max so oft wie die Bildwiederholfrequenz ist neu zu zeichnen und nicht öfter.
Ich denke nicht das einfache Buttons, Fortschrittsbalken und Statustexte mit der Bildwiederholfrequenz synchronisiert werden sollten. Zum einen kann die u.U. recht hoch sein so das dadurch eine erhebliche Systemlast entstehen kann und zum anderen kann keiner von uns so schnell lesen. Die vorgeschlagenen 10 Hz halte ich für einen guten Kompromiss aus möglichst geringer Last und möglichst aktueller Information. Es gibt sicher auch Infos die mit einer anderen Frequenz aktualisiert werden können/müssen (darüber kann man auf jeden Fall diskutieren) aber für die meisten Fälle sind 10 Hz sicher angemessen.
Grüße
Erik
-
Beim Beispiel der GUI ist es IMHO durchaus denkbar das man das nötige Hintergrundwissen auch dadurch erlangt das man viele unterschiedliche GUI-Programme programmiert und dabei mal verschiedene Techniken aktiv benutzt, auch kann es was nützen wenn man das alles auf mehreren verschiedenen GUI-Implementierungen ausprobiert um einfach mal ein Gefühl dafür zu bekommen welche Umsetzung sich wie am praktischsten benutzen lässt und eine weitere Methode ist simples lernen indem man Bücher ließt, Tutorials durcharbeitet oder sich mit anderen erfahrenen Programmierern unterhält. Ich behaupte mal das man nicht unbedingt bereits eine GUI implementiert haben muss um eine ordentliche GUI implementieren zu können. Genauso muss man nicht zwangsläufig ein OS implementiert haben um ein ordentliches OS implementieren zu können, es reicht wenn man sich das nötige Wissen auf anderem Wege besorgt (man sollte z.B. schon mal Treiber und sonstige systemnahe SW programmiert haben).
Man muss vielleicht nicht, aber es ist sehr hilfreich. Vielleicht bist du ein völlig anderer Typ als ich, aber ich lerne besser, wenn ich etwas ausprobieren kann als wenn ich wochenlang theoretische Bücher, Tutorials und Meinungen anderer lese.
Natürlich ist es auch hilfreich, Programme für unterschiedliche GUIs geschrieben zu haben. Das gibt einem ein Gefühl dafür, wie typische Interfaces aussehen (Aber leider nicht warum. Das erfährt man dann, wenn man es anders macht und damit auf der Schnauze landet.) und vielleicht gefallen einem ja Aspekte von einem Interface, an die man vorher nicht gedacht hat, und die man dann nachbauen will. Was es einem nicht gibt, ist ein Gefühl, wie man das Interface am geschicktesten implementiert, ohne Schiffbruch zu erleiden.
Trotzdem ist es momentan so das Ihr eher am Fassadenputz arbeitet anstatt mal ein ordentliches Fundament hinzulegen, tyndur macht auf mich eher den Eindruck von sowas (http://www.scheissprojekt.de/hausbau.html).
Dann zähl mal den ganzen Fassadenputz auf, den wir in letzter Zeit gemacht haben... Ganz ehrlich: Ich glaube, wir machen teilweise zu wenig Fassadenputz, der ist es nämlich, der Leute interessiert. Wenn es lange keinen sichtbaren Fortschritt gibt (wie im Moment), dann flaut die ganze Entwicklung ab.
IPC wurde hier doch nun schon mehr als einmal diskutiert und es ist da eine ziemlich reichhaltige Fülle an Vorschlägen in diesem Forum versteckt, da sollte sich doch auch was passendes für tyndur finden lassen. ;)
Und das Ergebnis war, dass alle Methoden irgendwie Mist sind. Dann kann ich auch gut den aktuellen Mist nehmen. Die wirklich konsequente Schlussfolgerung wäre, wenn ich mal so provokant sein darf, dass man einen Monolithen bauen sollte. ;)
-
Hallo,
Man muss vielleicht nicht, aber es ist sehr hilfreich. Vielleicht bist du ein völlig anderer Typ als ich, aber ich lerne besser, wenn ich etwas ausprobieren kann als wenn ich wochenlang theoretische Bücher, Tutorials und Meinungen anderer lese.
Natürlich gibt es unterschiedliche Menschen, die Welt wäre auch extrem langweilig wenn es anders wäre. Ich persönlich hab es noch nie erlebt das 'Theorie == Praxis' false ergeben hätte, solange natürlich die Vorgänge in der Praxis vollständig verstanden sind aber gerade das trifft ja auf Software immer zu da diese (als ganzes) ein hermetisch abgeschlossenes und streng deterministisches System darstellt. Mir ist klar dass das für viele keine intuitive Vorgehensweise darstellt aber ich behaupte das diese Methode den kleinsten Aufwand für das selbe Ergebnis erfordert.
Wie man grundsätzlich gute Software erstellt sollte zur handwerklichen Basis eines jeden ernsthaften Softwareentwicklers gehören, das trifft nicht nur auf die GUI zu.
Dann zähl mal den ganzen Fassadenputz auf, den wir in letzter Zeit gemacht haben...
Okay, in die Kategorie Fassadenputz gehört LIOv2 nun auch nicht gerade, aber zum Fundament zählt das VFS bei einem Micro-Kernel-OS wiederum auch nicht wirklich.
Ganz ehrlich: Ich glaube, wir machen teilweise zu wenig Fassadenputz, der ist es nämlich, der Leute interessiert. Wenn es lange keinen sichtbaren Fortschritt gibt (wie im Moment), dann flaut die ganze Entwicklung ab.
Dafür hab ich volles Verständnis, die Menschen sind nun einmal so. Aber eben deswegen wäre es ja so wichtig erst mal ein sauberes und stabiles Fundament zu haben damit man später, wenn man dann zum Fassadenputz kommt, nicht andauernd durch nacharbeiten am Fundament unterbrochen wird.
Und das Ergebnis war, dass alle Methoden irgendwie Mist sind.
Ich weiß ja nicht in welchen Foren Du so alles mitliest aber hier gab es durchaus auch andere Ansichten. Vielleicht hättest Du Dich in die entsprechenden Diskussionen auch ein wenig aktiver einbringen müssen, wenn Du etwas für Mist hältst dann solltest Du das klar ansprechen damit Du entweder die tatsächliche Genialität erkennst oder dieser Mist beseitigt werden kann.
Die wirklich konsequente Schlussfolgerung wäre, wenn ich mal so provokant sein darf, dass man einen Monolithen bauen sollte. ;)
Ja Du darfst so provokant sein. Wenn das Deine ehrliche Meinung darstellt dann frage ich mich aber erst recht warum tyndur so ist wie es ist.
Das Problem an dieser Meinung ist das wenn irgendwann mal einer kommt der das Gegenteil beweist das diese Meinung dann ein Irrtum darstellt. ;)
Grüße
Erik
-
Ich persönlich hab es noch nie erlebt das 'Theorie == Praxis' false ergeben hätte, solange natürlich die Vorgänge in der Praxis vollständig verstanden sind
Da muss ich wiedersprechen, allerdings insofern, dass man eigentlich nie die Praxis vollständig verstanden hat bzw. einfach nicht alle Faktoren kennt oder berücksichtigen kann.
Deswegen ist ja halt so oft "Theorie == Praxis" false. Denn würde man davon ausgehen das "Theorie == Praxis" true ist, wieso muss man dann viele Dinge erst üben bis man sie wirklich kann oder wieso scheitern viele in der Praxis die nur die Theorie kennen?
-
Hallo,
allerdings insofern, dass man eigentlich nie die Praxis vollständig verstanden hat bzw. einfach nicht alle Faktoren kennt oder berücksichtigen kann.
Gerade diese Einschränkung ist es die es zu berücksichtigen gilt, die trifft auf Software grundsätzlich nicht zu. Software ist immer ein hermetisch abgeschlossenes und streng deterministisches System! Gibt es da etwa gegenteilige Meinungen?
Deswegen ist ja halt so oft "Theorie == Praxis" false. Denn würde man davon ausgehen das "Theorie == Praxis" true ist, wieso muss man dann viele Dinge erst üben bis man sie wirklich kann oder wieso scheitern viele in der Praxis die nur die Theorie kennen?
Diese Frage treibt mir ein spontanes Schmunzeln ins Gesicht. Klar gibt es auch Dinge die sich wohl auf ewig vollständiger Kenntnis entziehen, spontan fallen mir da Frauen ein (sollte da tatsächlich jemand anderer Meinung sein so darf er gerne im OffTopic-Bereich einen passenden Thread aufmachen und diesen hier verlinken aber dieses Sub-Forum ist für eine derartige Diskusion wohl eindeutig nicht der richtige Platz). Aber für die meisten technischen Systeme sollte es möglich sein deren Wirkmechanismen vollständig zu verstehen, selbst bei chaotischen Systemen kann man in gewissen Grenzen mit Häufigkeiten u.ä. rechnen. Welcher (bereits tote) Physiker war es noch mal der das ganze Universum als streng deterministisch betrachtet hat? Wenn also 'Theorie == Praxis' doch mal 'false' ergibt dann nur weil man eben noch keine vollständige Systemkenntnis erlangt hat.
Grüße
Erik
-
Software ist immer ein hermetisch abgeschlossenes und streng deterministisches System! Gibt es da etwa gegenteilige Meinungen?
Naja, die Hardware auf der die Software läuft ist das Problem.
Aber für die meisten technischen Systeme sollte es möglich sein deren Wirkmechanismen vollständig zu verstehen, selbst bei chaotischen Systemen kann man in gewissen Grenzen mit Häufigkeiten u.ä. rechnen.
Schonmal was von der Chaostheorie gehört?
Es gibt so viele Faktoren, gerade bei technischen Systemen, die man einfach nicht voraussehen kann, noch kennt man heute alle.
Was mir noch zwecks Theorie einfällt, ist Physik, da wird soviel weggedacht, damit es sich einfacher rechnet, aber 100%ig genau ist es deswegen nicht. Ich kenne einen Fall wo ein nicht studierter eine Anlage besser bedienen konnte (zwecks Erfahrung aus der Praxis und durch Beobachtung) als ein Ingeneur.
Jetzt aber genug OT ;)
-
Software ist immer ein hermetisch abgeschlossenes und streng deterministisches System! Gibt es da etwa gegenteilige Meinungen?
Naja, die Hardware auf der die Software läuft ist das Problem.
Und solange man annimmt, dass die Hardware funktioniert, ist sie ebenfalls streng deterministisch... von defekter Hardware gehen wir hier ja nicht gerade aus.
Schonmal was von der Chaostheorie gehört?
Ja, die kann man mit Statistik erschlagen. :-)
-
Und solange man annimmt, dass die Hardware funktioniert, ist sie ebenfalls streng deterministisch... von defekter Hardware gehen wir hier ja nicht gerade aus.
Ich will damit auch nur sagen, dass es die Dinge sind, die man nicht einplant bzw. einplanen kann, die alle so schön deterministisch sind, die einem dann in der Praxis nen Strich durch die Rechnung machen.
Ja, die kann man mit Statistik erschlagen.
Jap, aber halt nicht zu 100%.
-
Ich glaube ihr solltet eure Ironiedetektoren mal kalibrieren lassen.
-
Hallo,
Ich glaube ihr solltet eure Ironiedetektoren mal kalibrieren lassen.
Also ich hab meine Aussagen betreffend des unterstellten Determinismus eigentlich alle ernst gemeint.
Der nun seit 50 Jahren tote Physiker hieß übrigens Erwin Schrödinger. Wer sich die Gedanken hinter seinem bekannten Tierexperiment ansieht versteht besser was gemeint ist.
Eigentlich lehne ich ja die Existenz von Chaos grundsätzlich ab, IMHO ist Chaos nur ein Hilfskonstrukt von Leuten die zu Faul sind ein System komplett auszumessen um es eben komplett zu kennen, aber jedes mal wenn ich das Zimmer meines Sohnes betrete weiß ich das es Chaos wirklich real gibt. ;)
Grüße
Erik
-
Eigentlich lehne ich ja die Existenz von Chaos grundsätzlich ab
Ich wollte mit der Chaostheorie auch nur darauf hinaus, des ich dem Menschen die Fähigkeit abspreche, ein so komplexes System wie die Natur 100%ig genau vorraus zu sagen. Dazu gibt es einfach zu viele Faktoren und alleine schon das Erfassen/Messen aller Faktoren (im Endeffekt müsste man ne komplette Momentaufnahme des gesamten Systems, sprich des gesamten Universums machen, um alle Faktoren zu kennen) ist einfach unmöglich. Weil ja jeder Faktor rein theoretisch einen Einfluss haben könnte, der das Ergebnis verändert (die meisten Wirkungen dürften sich selbst unserer Vorstellungskraft entziehen).
Und ein System als abgeschlossen zu betrachten, ist auch nur ein Hilfskonstrukt um externe Einflüsse ausschließen zu können und damit Sachen einfacher zu machen.
-
Hallo,
im Endeffekt müsste man ne komplette Momentaufnahme des gesamten Systems, sprich des gesamten Universums machen, um alle Faktoren zu kennen
Es ist natürlich unmöglich eine vollständige Momentaufnahme das gesamten Universums zumachen, selbst ich bestreite das nicht, aber das Universum deswegen als chaotisch zu bezeichnen ist eben auch keine Lösung. Darauf zielt meine Weigerung der Akzeptanz des Chaos ab, auf nicht mehr und nicht weniger.
die meisten Wirkungen dürften sich selbst unserer Vorstellungskraft entziehen
Hm, zumindest die Fantasie wird doch allgemein als grenzenlos bezeichnet, vielleicht sollten wir die Meinung der Allgemeinheit (also des Pöbels) in diesem speziellen Fall doch mal ernst nehmen. ;)
Und ein System als abgeschlossen zu betrachten, ist auch nur ein Hilfskonstrukt um externe Einflüsse ausschließen zu können und damit Sachen einfacher zu machen.
Bei den meisten physikalisch Dingen trifft das sicher zu, ja, aber Software ist IMHO tatsächlich ein abgeschlossenes System weil alle potentiellen Einflüsse ja auch durch die Software kontrollierbar sind. Die Auswirkungen die ein IRQ potentiell haben kann sind durch die Software vorgegeben da auch der IRQ-Handler ein Teil der Software ist und damit unter der Kontrolle des Softwareentwicklers steht. Selbst die Zeitpunkte an denen ein IRQ möglich ist sind durch die Software vorgegeben da die zugrunde liegende Hardware ja von der Software konfiguriert/manipuliert wird und damit ebenfalls unter der Kontrolle des Softwareentwicklers steht. Wir schließen jetzt mal Fehler in der Hardware aus und nehmen auch an das der Softwareentwickler die vollständige Hardwaredokumentation komplett gelesen und verstanden hat.
Grüße
Erik
-
Was ist eigentlich mit so sachen, das es möglich ist von außen fremden Code einzuschleußen, passt das da noch rein? Ich meine damit nicht mal unbedingt Buffer-Overflows oder sowas, sondern, war es nicht sogar Firewire (oder Thunderbolt??), dass einem Gerät zuviel Möglichkeiten (hardwaretechnisch) gegeben wurden, so dass Code ohne Eingriff der Software eingeschleust werden kann.
-
firewire war der übeltäter. thunderbolt wird wohl ähnlich sein.
und zum thema gui: die grafikkarte ist da keine ausnahme. opengl im browser hardwarebeschleunigt heißt, webseitencode hat vollzugriff auf physischen speicher (falls keine iommu aktiv).
-
und zum thema gui: die grafikkarte ist da keine ausnahme. opengl im browser hardwarebeschleunigt heißt, webseitencode hat vollzugriff auf physischen speicher (falls keine iommu aktiv).
Aber nur auf vom GUI "genehmigten" RAM oder?
-
DMA ist DMA. :roll:
Shaderprogramme sind Code, der auf der Grafikkarte ausgeführt wird... und den man vorher aus Performancegründen nicht analysiert.
-
Ich wusste nicht das man mit Hilfe von Shadercode soviel (auf jeglichen Speicher zugreifen) machen kann. Ist dass dann aber nicht immer ein Problem (auch bei normalen Anwendungen)?
-
Hallo,
Was ist eigentlich mit so sachen, das es möglich ist von außen fremden Code einzuschleußen, passt das da noch rein?
Hm, das ist in der Tat eine hochgradig philosophische Frage. Ich drücke mich jetzt einfach mal vor einer richtigen Antwort und definiere das der Schadcode Teil des geschlossenen Systems "Software" ist. ;)
Solange Shadercode ungeprüft in die Grafikkarte gespielt wird stellt dieser auch immer ein Sicherheitsrisiko dar, egal welche Anwendung den einschleppt.
Sollte sich Thunderbolt wirklich so durchsetzen wie Intel und Apple das wollen dann müssen auf jeden Fall auch IOMMUs zur Standardausrüstung aller PCs gehören, nebst einem OS das diese IOMMUs auch anständig zu nutzen weiß. Bei meinem privaten Laptop hab ich den Chip fürs Firewire vom Mainboard dauerhaft entfernt, das erspart mir nicht nur ein potentielles Sicherheitsleck sondern bringt auch minimal längere Akkulaufzeit.
Grüße
Erik
-
Ich wusste nicht das man mit Hilfe von Shadercode soviel (auf jeglichen Speicher zugreifen) machen kann. Ist dass dann aber nicht immer ein Problem (auch bei normalen Anwendungen)?
Eher nein. Code, der von der CPU ausgeführt wird, unterliegt dem Speicherschutz, der von CPU und Betriebssystem garantiert wird. Wenn du 3D-Spiele meinst: Ja, das ist auch ein prinzipielles Problem, aber nicht praktisch relevant (wenn die Software erstmal im System ist, reicht ein Standard-Exploit des OS; bei Sandbox-Umgebungen wie Browsern ist das schon schwieriger).
-
Solange Shadercode ungeprüft in die Grafikkarte gespielt wird stellt dieser auch immer ein Sicherheitsrisiko dar, egal welche Anwendung den einschleppt.
Wird der Code denn vom Treiber überprüft und selbst wenn, auch die (Treiberprogrammierer) machen Fehler?
Was mich daran nur gerade wundert, wieso habe ich davon noch nie was gehört? Ich meine das ist doch schon nen potentielles Risiko, vorallem wenn man dann an WebGL denkt.
-
Wird der [Shader]Code denn vom Treiber überprüft und selbst wenn, auch die (Treiberprogrammierer) machen Fehler?
Nein, wenn du den Code auf der CPU analysierst, könntest du ihn auch gleich dort ausführen. Das will man aus Performance-Gründen nicht.
Was mich daran nur gerade wundert, wieso habe ich davon noch nie was gehört? Ich meine das ist doch schon nen potentielles Risiko, vorallem wenn man dann an WebGL denkt.
Wenn du Hardwarebeschleunigung um jeden Preis möchtest, dann ist ein potentielles Risiko nicht wichtig genug. Siehe z.B. hier (http://blog.fefe.de/?ts=b32cb04e).
-
Auch wenn´s total OT ist, aber das mit dem Bundestrojaner ist im Mom viel interessanter, vorallem da wir uns da auf das verlassen was einige wenige sagen, die auch auch verarscht worden sein können.
-
Hallo,
Wenn du Hardwarebeschleunigung um jeden Preis möchtest, dann ist ein potentielles Risiko nicht wichtig genug.
Wie wahr!
Ich finde ja hier wären die HW-Designer mal in der Pflicht bestimmte physische Adressbereiche (z.B. 0xFEExxxxx) hardcodiert auszufiltern damit wenigstens ein paar der ernsten Design-Probleme der x86-Plattform-Architektur versteckt werden.
Siehe z.B. hier (http://blog.fefe.de/?ts=b32cb04e).
Der Artikel ist interessant, aber noch interessanter (zumindest für mich) ist der Link auf Attacken gegen die IOMMU von Intel. Einer der häufigsten Sätze in dem PDF ist "This attack should never be possible on a well-designed architecture.", wenn das mal kein echtes Lob an Intel ist. In diesem Dokument werden eine ganze Menge an x86-spezifischen Design-Features aufs Korn genommen (vor allem im Zusammenhang mit Interrupts). Ich muss feststellen das meine Entscheidung in meinen CPUs keinen Local-APIC o.ä. haben zu wollen (und nur einen einzigen IRQ-Controller im Chip-Satz) mir doch unzählige Problemen erspart. x86 ist die Plattform auf der die fortschrittlichsten Schutzmechanismen (SMEP/IOMMU/....) existieren (von meiner Plattform, die ja eben noch nicht existiert, mal abgesehen ;)) und trotzdem ist es die anfälligste Plattform überhaupt, einfach nur weil das meiste davon extrem stümperhaft entwickelt/implementiert wurde oder weil man Problem-Relikte aus der Urzeit mitschleppt. Klar sind bei x86 auch deswegen so viele Lücken gefunden worden weil man dort auch am meisten sucht aber ich bin trotzdem der Meinung das die allgemeine Computer-Sicherheit auf diesem Planeten einen echten Schritt nach vorn machen würde wenn man x86 einfach komplett einstampft und verschwinden lässt.
Grüße
Erik
-
Andere Architekturen z.B. ARM kennen doch auch DMA (und sogar in der veralteten, es muss physisch zusammenhängender Speicher sein, Variante). Wie sicher ist das denn dort?
Dort kann doch bestimmt auch der Shader-Code dann auf den gesamte RAM zugreifen oder? Bzw. kann man dort nicht z.B. auch steuern wieviel RAM z.B. die Graka bekommt? Dann könnte man also auch ganz leicht diesen Bereich verändern.
-
Klar sind bei x86 auch deswegen so viele Lücken gefunden worden weil man dort auch am meisten sucht aber ich bin trotzdem der Meinung das die allgemeine Computer-Sicherheit auf diesem Planeten einen echten Schritt nach vorn machen würde wenn man x86 einfach komplett einstampft und verschwinden lässt.
Selbst Intel hat's schon oft genug versucht (iAPX 432, i860, i960 und auch ARM) und nicht geschafft. Microsoft hat's mitgetragen (WinNT für PowerPC, MIPS, DEC Alpha) und es ist nichts draus geworden. Du wirst diesen Dreck einfach nicht los. ARM ist im mobilen Bereich weit überlegen, aber weder im Server- noch im Workstation-Bereich denkt man auch nur darüber nach.
Andere Architekturen z.B. ARM kennen doch auch DMA (und sogar in der veralteten, es muss physisch zusammenhängender Speicher sein, Variante). Wie sicher ist das denn dort?
Wer suchet, der findet. Kein System ist hundertprozentig sicher. Aber ein System, was von Grund auf einfach konzipiert ist, kann man einfach schützen. Bei einer Plattform, wo der simulierte Tastaturcontroller den RAM-Zugriff und den CPU-Reset steuern können muss, ist das nicht mehr so einfach möglich.
Gruß,
Svenska,
dem das ganze Thema hier viel zu OT ist.
-
Hallo,
und sogar in der veralteten, es muss physisch zusammenhängender Speicher sein, Variante
Warum sollen die HW-Geräte auf anderen Architekturen nicht auch Scatter/Gather unterstützen können? Ob die HW-Geräte mit verstreutem physischen Speicher zurecht kommen hat nichts mit der CPU zu tun.
Gegen busmasterfähige HW-Geräte hilft grundsätzlich nur eine anständige IOMMU (und dazu noch eine gescheite Routing-Strategie im Chipsatz), egal auf welcher Plattform. Das Problem an x86 ist das dessen Komplexität total aus dem Ruder gelaufen ist. Weißt Du genau wie viele Ausführungsmodi eine moderne x86-CPU überhaupt hat? Neben den 4 PM-Ringen (und noch dem Real-Mode und Virtual-Real-Mode) gibt des da noch den SMM (und weil der eine Design-Katastrophe mit Sicherheitslecks ist dazu noch einen SMM-Monitor oder so ähnlich), irgendwas fürs TXT und bestimmt gibt es noch ein paar Dinge die sich meiner Vorstellungskraft gänzlich entziehen. Alle anderen CPU-Architekturen haben genau 2 (mache auch 3) Modi: "UserMode" und "SystemMode" (manche noch einen "ÜberSystemMode" um damit z.B. Page-Table-Walks in SW machen zu können). Simplizität ist für sichere Designs ein essentiell wichtiges Design-Paradigma.
wo der simulierte Tastaturcontroller den RAM-Zugriff und den CPU-Reset steuern können muss
Das muss man sich erst mal in aller Ruhe zwischen den Hirnwindungen setzen lassen, was es bei x86 alles an Unsinn gibt. Ich habe wirklich Ehrfurcht vor jedem der dafür allen ernstes versucht ein anständiges OS zu programmieren das all diese wirren Dinge auch erfolgreich benutzt.
Grüße
Erik
-
Gerade das periodische händische Umkopieren des gesamten Framebuffers von einem SW-Buffer im normalen RAM in den Video-Speicher der Grafikkarte ist deutlich aufwendiger als wenn die Grafikkarte sich die Bilddaten selber per Busmastering aus dem Speicher holt.
Also man kopiert ja meistens nicht den gesamten Framebuffer (das will man ja gerade vermeiden), sondern nur das was sich geändert hat und dazu muss man auch lesen und das ist aus dem Grakaspeicher sehr langsam. Hat man Hardwarebeschleunigung nutzt man doch genau dafür BitBlt (das vergleicht doch und kopiert nur das was sich geänder hat, oder?).
Im "VBE-AF07.pdf" von vesa.org unter public documents steht einiges über den Treiber "VBEAF.DRV". Ich selber habe noch keine Erfahrungen damit gemacht.
Dirk
-
Ich sehe den Thread gerade eben erst, und möchte nochmal bei den Shadern einhaken.
Ich weiß jetzt nicht, wie das bei D3D aussieht, aber GLSL-Shader können nicht einfach auf irgendwelchen RAM zugreifen.
Ein Beispiel: http://pastebin.de/21920
Der Shader bekommt seine Daten entweder aus Buffern, die vorher von der Anwendung (und dadurch vom Treiber) an die "in-Variablen" gebunden werden (die bekommt der Shader per Vertex) oder per uniform (Daten per Render-Call). Das Weiterreichen von Daten innerhalb der Shader erfolgt mit out/in, die Ausgabe kommt per out entweder in den Framebuffer oder in Multiple-Render-Targets (muss vorher von der Software gebunden werden).
So etwas wie Pointer o.Ä. kennt die Sprache gar nicht, der Zugriff auf Daten erfolgt in einem sehr engen Rahmen.
Von daher scheinen mir diese Entrüstungen, die es über WebGL und Shader gab, ziemlich übertrieben.
-
Bei VirtualBox sind die Extensions für 3D-Hardware-Beschleunigung standardmäßig deaktiviert.
Wenn ich das richtig sehe, bedeutet die Ausführung von Shader-Code auf der GPU dort eine Verletzung des Sandbox-Prinzips. Auch bin ich mir nicht ganz sicher ob Grafiktreiber im Allgemeinen Vorkehrungen gegen Schadcode getroffen haben.
Bezüglich DMA ging ich bisher davon aus, dass bestimmte Bereiche im RAM gemappt werden. Falls das zutrifft könnte man Speicherschutz mit Segmenten erreichen. Abgesehen davon bin ich nicht sehr glücklich darüber, dass die Ingenieure von PC-Hardware davon auszugehen scheinen, dass Bedrohungen für ein System ausschließlich durch Software bestehen und folglich den Hardware-Komponenten eines Systems bedingungslos vertrauen.
-
Hallo,
das Problem sind nicht die Programme in den High-Level-Shader-Sprachen die für generische abstrakte Shader entwickelt werden sondern der fertig kompilierte Objekt-Code der von den realen Shadern ausgeführt wird. Dort gibt es meines Wissen nach echte 64Bit-Pointer in den modernen Shadern (sowohl bei AMD, NVidea als auch bei Intel). Die GPUs haben auch eine Art MMU, mit der ganz gewöhnliches Paging gemacht wird, damit die Texturen und sonstigen Daten die ja verstreut im physischen RAM liegen zusammenhängend benutzt werden können, die GPUs haben quasi eine eigene virtualisierte Sicht auf den RAM. Deswegen macht es auch theoretisch nichts aus ob Texturen u.ä. wirklich im lokalen GPU-RAM oder nur im normalen Haupt-RAM liegen, von der Performance mal abgesehen. In den Treibern wird wohl keine Sicherheitsüberprüfung des Shader-Objekt-Code stattfinden, dazu müsste dort eine recht umfangreiche Code- und Daten-Flussanalyse durchgeführt werden um feststellen zu können ob irgend ein Pointer nicht doch mal auf Speicherbereiche zeigt die eigentlich nicht gewünscht sind. Spätestens wenn die Shader-Programme in der Lage sind Texturen u.ä. zur Laufzeit von der SW flexibel zur Verfügung gestellt zu bekommen ist auch das nicht mehr sinnvoll möglich.
Es gibt also sehr viele Punkte an denen man ansetzen könnte um mit Hilfe der GPU den normalen RAM zu manipulieren, z.B. einfach nur das GPU-Paging zu verbiegen um anderen physischen Speicher anzusprechen. Ich wette hier stecken die Viren-Programmierer noch in der sehr frühen Konzeptionierungsphase, aber sollte WebGL wirklich so kommen wie derzeit beabsichtigt dann dürfte das ein neues lukratives und sicher auch interessantes Betätigungsfeld für die Viren-Programmierer und deren Kontrahenten bei den AV-SW-Herstellern werden. Ich gehe davon aus das die Einführung von WebGL in erster Linie der Aufrechterhaltung der Einnahmequellen der AV-SW-Hersteller dient. ;)
Bezüglich DMA ging ich bisher davon aus, dass bestimmte Bereiche im RAM gemappt werden.
Wie bzw. durch welche HW-Komponente soll das den passieren? Ohne eine IOMMU hat jede busmasterfähige HW vollen Zugriff auf den gesamten physischen Adressraum, sogar auf andere HW-Komponenten (falls der Chipsatz das unterstützt, in der PCI-Spec steht dazu "implementierungsspezifisch"). Das trifft übrigens nicht nur auf PCI und seine Erben zu sondern gilt auch für EISA, VLB u.a.m. Das einzigste was wirklich hilft ist eine gute IOMMU die direkt im Chipsatz steckt und jeden Zugriff der von der Peripherie-HW kommt filtert und nur vom OS-Kernel kontrolliert wird.
Falls das zutrifft könnte man Speicherschutz mit Segmenten erreichen.
Sowas traust Du Dich vorzuschlagen? Respekt! Die bösen Segmente will doch heute niemand mehr haben. Die waren schließlich zu DOS-Zeiten ein Quell grenzenloser Freude. ;)
Abgesehen davon bin ich nicht sehr glücklich darüber, dass die Ingenieure von PC-Hardware davon auszugehen scheinen, dass Bedrohungen für ein System ausschließlich durch Software bestehen und folglich den Hardware-Komponenten eines Systems bedingungslos vertrauen.
Willkommen in der Realität! Dieses bedingungslose Vertrauen erstreckt sich übrigens auch auf die Treiber, mit der passenden Konfiguration kann jede busmasterfähige HW eine echte Bedrohung werden (falls dem nicht eine IOMMU Einhalt gebietet, aber die wird vom OS-Kernel sicher auch nur anhand der Wünsche der potentiell fehlerhaften Treiber konfiguriert, wenn Du Dir jetzt mal mein IPC-Konzept anschaust wirst Du vielleicht feststellen das Segmente hier einiges zu bieten haben). Wenn Du die Bedrohungen durch Firewire kennst und Dir überlegst was ein vollwertiger PCI-Express-Link nach draußen erst alles anstellen kann dann dürfte es Dir sicher auch schwer fallen die Idee von Thunderbolt zu verstehen.
Grüße
Erik
-
Du sprichst also vom fertigen Code, der dann auf der GPU läuft? An den komme ich per WebGL doch gar nicht ran.
Bei normaler Software ist das wieder was anderes, da kam mit OpenGL 4 (.2 ?) gerade die Möglichkeit, die fertigen Shader vom Treiber abzuholen und später wieder zu laden, um zeitaufwändiges neu-kompilieren beim Programmstart zu verhindern ;)
-
OT: Gibt es ein standardisiertes Protokoll zur Kommunikation mit OpenGL-Hardware? Wenn ja, würde ich damit irgendwann Grafikprimitive, GUI Komponenten und Desktop beschleunigen. Ansonsten gibt es auch noch Mesa3D.
-
Hallo,
Du sprichst also vom fertigen Code, der dann auf der GPU läuft? An den komme ich per WebGL doch gar nicht ran.
Ja. Ist doch egal, es gibt Wege und das reicht. Und wer richtigen Schadcode erstellen will wird sicher nicht den Compiler im Treiber benutzen sondern andere/eigene Wege finden.
Die Hersteller der GPUs sind auf jeden Fall sehr daran interessiert sich von den Wettbewerbern durch spezielle Features abzuheben (was ansich ja auch völlig legitim ist und zu jeder gesunden Marktwirtschaft dazugehört), damit die Programme diese Features aber auch nutzen können müssen sie den genauen Typ der vorhandenen GPU identifizieren können und das wird sicher auch bei WebGL gehen. Damit wird aber auch die Möglichkeit eröffnet GPU-spezifische Shader-Programme zu laden und die dürften im Interesse schneller Start-Zeiten und kurzer Download-Zeiten bereits vorkompiliert sein. Bis hier ist alles so wie von den GPU-Herstellern und von den Anwendungsentwicklern gewünscht nur leider profitieren davon auch die Schadcode-Programmierer, wenn Du da eine gute Idee hast wie die ersten Gruppen trotzdem zu ihren Zielen kommen und gleichzeitig die letzte Gruppe ausgeschlossen wird so wird man Deine Ideen sicher berücksichtigen ansonsten gehe ich davon aus das die WebGL-Designer eben dieses Risiko einfach eingehen werden und die Anwender werden es früher oder später auch müssen wenn sie nicht vom graphischen Schnick-Schnack im Web komplett ausgeschlossen werden wollen.
OT: Gibt es ein standardisiertes Protokoll zur Kommunikation mit OpenGL-Hardware?
Nein. Und es gibt auch keine "OpenGL-Hardware", es gibt höchstens GPUs mit deren Features es möglich ist einen OpenGL-konformen Treiber zu entwickeln. OpenGL beschreibt wimre nur eine High-Level-API (das Interface zwischen Treiber und Applikation) und eben die Funktionalitäten die damit verfügbar gemacht werden sollen.
Grüße
Erik
-
Hallo,
ich hab zu dem Thema Busmaster-fähige HW und IOMMU noch ein wenig nachgedacht.
Moderne HW unter stützt ja für gewöhnlich das Scatter/Gather um die Daten, die sich im physischen RAM ja total zerstreut befinden (Paging sei dank), wieder anständig zusammen zu suchen. Wenn sich im Chipsatz immer eine IOMMU befindet dann gibt es doch damit die Möglichkeit das sich die von der HW benötigten Daten wieder linear am Stück in einem zusätzlichen virtuellen Adressraum befinden und somit die Notwendigkeit für Scatter/Gather-Unterstützung in der HW entfällt. Das würde sicher die Entwicklung von Treibern erleichtern, wer das nicht glaubt sollte sich mal die zugehörigen Strukturen in EHCI, xHCI oder AHCI ansehen, und auch die HW etwas weniger komplex machen. Auch die GPUs bräuchten keine eigene MMU mehr da das ja schon alles die IOMMU macht.
Ich hoffe das sich das Konzept von IOMMUs möglichst bald durchsetzt, da ich davon ausgehe das damit einiges für die Computer-Sicherheit getan werden kann.
Hat denn einer von Euch vor die IOMMU in sein OS mit einzubinden?
Grüße
Erik