Nachrichten

161

OS-Design / Re: GUI LowLevel

« am: 08. October 2011, 17:30 »

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?

162

OS-Design / Re: EOI, wann senden?

« am: 08. October 2011, 17:26 »

Bei Edge-Triggered-IRQs reicht es ja auch völlig wenn der IRQ-Controller nur so lange blockiert wird bis der IRQ an die nächste Verarbeitungseinheit erfolgreich ausgeliefert wurde, schließlich steht ja kein permanent aktives Signal (wie bei einem Level-Triggered-IRQ) an das man erstmal ignorieren muss bis der Treiber das Ereignis im HW-Gerät auch tatsächlich bearbeitet hat. Bei Edge-Triggered-IRQs sendet das HW-Gerät pro Ereignis normalerweise auch nur genau einen IRQ zum IRQ-Controller, alles andere würde ich als Defekt im HW-Gerät bezeichnen. Dazu kann (aber nicht muss) im HW-Gerät noch ein internes automatisches Maskenregister existieren das nachfolgende gleiche Events (z.B. weitere empfangene Ethernet-Frames in einem Netzwerkkontroller) blockiert bis der Treiber diese Event-Art komplett abgearbeitet hat (z.B. den Empfangspuffer komplett geleert hat).

Genau das habe ich mir gedacht.

Also mit "nochmal" meinte ich einen neuen IRQ (dein Bsp. Ethernet-Karte), falls die so schnell kommen das der vorherige IRQ noch im Handler steckt, kann es sein das der neue IRQ an einen anderen APIC geschickt wird und somit der Handler nochmal aufgerufen wird.

Falls dem wirklich so ist, muss ich meinen Code von heute nochmal bearbeiten und den alten Zustand wiederherstellen (mit einer kleinen Veränderung).

Also bei level-triggered blockiert schon der IO-APIC bis ein EOI kommt, bei edge-triggered allerdings nicht, aber ich muss trotzdem ein EOI senden, damit das entsprechende Bit im Lokalen-APIC gelöscht wird.
Die Handler müssen also Multithreading-safe sein. Bei level-triggered tut es nicht weh und bei edge-triggered hat meine Variante den Vorteil dass das focus-processor Feature emuliert wird (womit man ein wenig mehr Performance rauskitzelt, aber nur ein winziges bißchen).

163

OS-Design / Re: EOI, wann senden?

« am: 08. October 2011, 12:15 »

Es können in einem System auch mehrere unabhängige IRQ-Controller existieren (so wie die vielen APICs in modernen x86-Computern)

Damit sind der (da es meistens, von Servern mal abgesehen, ja nur einen gibt) IO-APIC und die Local-APICs gemeint!?

Ich habe mir gerade noch mal die IO-APIC und Local-APIC Doku angesehen und beim IO-APIC steht da, dass edge-triggered IRQs nur "nochmal" gesendet werden, wenn der Empfänger nicht das entsprechende IRR-Bit gesetzt hat. Das wiederrum heißt, dass es durchaus passieren kann, das der Handler noch am Arbeiten ist und ein anderer Local-APIC den selben Handler wieder aufruft.
Der entsprechende IRQ (bzw. der gesamte IO-APIC) wird nur bei level-triggered IRQs bis zu einem EOI vom Lokalen-APIC geblockt, nicht aber bei edge-triggered. Dort wird nur so lange geblockt bis der Lokale-APIC den IRQ angenommen hat.

Soweit habe ich die Doku verstanden (was aber nix heißen muss ).

164

OS-Design / Re: EOI, wann senden?

« am: 08. October 2011, 09:43 »

Für jeden einzelnen Interrupt einen Thread zu erzeugen ist für meine Begriffe etwas unhandlich, weil ein kurzzeitiger IRQ-Sturm direkt zu einem OOM führen kann. Daher würde ich pro Gerätetreiber maximal einen ausstehenden IRQ-Handler zulassen. Queuen ist auch nicht besonders elegant, weil (je nach HW) der erste IRQ-Handler die Ursache für den zweiten IRQ beheben kann und der zweite Handler dann ins Leere greift. Einen IRQ-Handler-Thread pro Treiber und IRQ zu haben, finde ich besser.

Da habe ich mich dann missverständlich ausgedrückt. Ich will auch nur einen Thread pro IRQ und die Events werden dann gequeuet und dieser eine Thread arbeitet die dann ab. Nur dadurch das ich die Events übers IPC System schicke, wird jedes Mal (wenn nicht schon ein Thread vorhanden ist) ein neuer Thread erstellt.

Zwischen "IRQ bekommen" und "EOI senden" ist der Interrupt immer maskiert. Also brauchst du dir keine Sorgen machen, dass der gleiche IRQ auf einer anderen CPU auftaucht.

Ist das wirklich so? Da ich es so verstanden hatte, das edge-triggered IRQs nicht auf ein EOI warten.

Bsp. wären MSIs die ja edge-triggered sind und die werden bei mir dann per lowest-priority versendet und so kann es passieren, das auf CPU A IRQ 1 ankommt und während dessen das Event versendet wird, kommt IRQ 2 auf CPU B an (weil dessen Priorität jetzt kleiner ist) und der selbe Handler wird nochmal ausgeführt. Der IRQ ist ja nur im lokalen APIC maskiert und nicht direkt im Gerät oder?

Bisher hatte ich das abgefangen, indem ich einen per IRQ Counter hatte der den Startwert -1 hat. Bei jedem IRQ Eintritt wird er um 1 erhöht und wenn er ungleich 0 ist, wird direkt wieder aus dem IRQ Handler gesprungen (da bereits ein IRQ Handler das Event versendet). Der IRQ Handler der bereits läuft, dekrementiert nach dem senden des Events und des EOIs diesen per IRQ Counter und wenn das Ergebnis nicht negativ ist, wird nochmal ein Event versendet.
Dadurch serialisiere ich den ganzen Spaß und emuliere das "Focus-Processor" Feature älterer CPUs.

Die Frage ist aber, ob das wirklich nötig ist und soweit ich es halt verstanden habe, ist es das, aber die ganze Sache ist nicht so einfach.

165

OS-Design / Re: EOI, wann senden?

« am: 07. October 2011, 22:01 »

Boah, kannst du das nochmal irgendwie zusammenfassen Ich habe den Beitrag jetzt 3x gelesen und habe das Gefühl das wesentliche immer noch nicht erfasst zu haben.

Um es kurz zu machen, edge-triggered IRQs können nicht geshared werden, aber ist es möglich das 2 davon auf unterschiedlichen CPUs ankommen bevor auf der ersten CPU der IRQ maskiert wurde? Weil dann müsste ich mich um "Multi-Threading" im IRQ Handler kümmern, ansonsten nicht.
Level-triggered IRQs können geshared werden, aber es wird kein neuer IRQ ausgelöst, bevor der alte nicht per EOI beendet wurde, somit kann man den IRQ wunderbar maskieren und bekommt keinen neuen.

Man würde also nen IRQ bekommen, am besten sofort maskieren, die Events versenden und den EOI senden!?

Ich habe im Moment noch das Problem, dass das Senden der Events ganz schön lange dauern könnte bei level-triggered IRQs. Denn das könnten ja mehrere Geräte sein und dann müsste, bei meinem Design, pro Event ein Thread erstellt werden (was ja nicht gerade billig ist). Ich würde da dann versuchen das ganze zu optimieren, in dem ich entweder bei Treibern, den Thread für die Events nicht zerstöre oder ich sagen würde, das alle Threads die gekillt werden, erstmal als "Zombie"-Threads im Task bleiben, damit bei neuen Threads weniger Arbeit nötig ist. Das wiederrum funktioniert nur gut, fürs Messaging, wo immer die gleiche Stack-Größe benötigt wird. Denn das ist das eigentlich zeitaufwändige, einen Bereich im Adress-Space für den Stack zu finden, der groß genug ist.

166

OS-Design / Re: EOI, wann senden?

« am: 07. October 2011, 20:33 »

Kann man ein EOI eigentlich auch gefahrlos für längere Zeit verzögern? Dann erspart man sich eigentlich doch das maskieren?

Das geht so weit ich weiß nur bei level-triggered IRQs (also PCI ohne MSI), edge-triggered IRQs interessiert das wohl eher weniger

Das ist auch gerade mein Problem, wo ich nicht so ganz durchsteige.

Nehmen wir an, ich bekomme einen IRQ (auf nem PIC-System) und maskiere den IRQ, sende halt die Events, sende dann den EOI. Kann es bis zu dem Zeitpunkt des Maskierens passieren das der selbe IRQ nochmal auftritt und dann nach dem IRET ausgeführt wird?

Andere Szenario, ich bekomme einen IRQ (auf nem IO-APIC SMP System) und maskiere den IRQ, sende halt die Events, sende dann den EOI. Kann es bis zu dem Zeitpunkt des Maskierens theoretisch auf einer anderen CPU zu dem selben IRQ kommen?

Allerdings war mir so, als wenn edge-triggered IRQs sowieso nicht shared waren oder? Damit hätte sich das Problem dann ja eh erledigt.

Ich würde den IRQ dann solange maskiert lassen, bis ein Treiber IRQ_HANDLED sendet (bzw. den Syscall macht) und dann wird der entsprechende IRQ wieder demaskiert.
Werden die IRQs dann irgendwie gequeuet oder gehen die verloren (während der IRQ maskiert ist)?

167

OS-Design / Re: EOI, wann senden?

« am: 07. October 2011, 17:31 »

In der Regel ist das entweder dann, wenn der Gerätetreiber den IRQ fertig behandelt hat (funktioniert eigentlich nur bei einem Monolithen, nehme ich an)

Wieso denkst du dass das nur in einem Monolithen funktioniert, weil die Zeit für das Fertigstellen bei einem MikroKernel länger dauert?

oder aber nachdem man den jeweiligen Interrupt maskiert hat, um das eine Gerät erstmal ruhigzustellen, bis der Treiber fertig ist.

Auch ne Möglichkeit, damit würde ich mir sogar ein wenig Code im IO-Apic Bereich ersparen (weil ich da ja davon ausgehen könnte, das kurz nacheinander auf verschiedenen CPUs der gleiche IRQ getriggert wurde).

Aber wo sind da die Vor- und Nachteile?

Bei beiden Varianten gibt es das Problem (ist es überhaupt eins oder geht es sogar gar nicht anders?), dass man immer warten muss bis ein Gerät fertig ist (und somit nur hoffen kann, das der IRQ schnell behandelt wird) und der nächste IRQ (was ja auch ein anderes Gerät sein könnte) behandelt werden kann.

Edit::

Ich glaube ich habe da nen Denkfehler drin. Wird der EOI nicht gesendet, lässt das dann effektiv auch andere IRQs auf der CPU nicht mehr zu? Weil wenn ja, dann muss ich es eh so machen, dass ich den Interrupt maskiere und dann den EOI sende.

168

OS-Design / EOI, wann senden?

« am: 07. October 2011, 16:59 »

Ich arbeite gerade an meinem Irq Code und da stellt sich mir mal wieder die Frage, wann sendet man einen EOI?

Wenn man alle Handler angetriggert hat oder wenn ein Handler bestätigt hat, dass es sein IRQ war? (Ich weiß das meistens nur die letzte Variante bei den meisten Systemen implementiert ist)

Interessant wäre noch zu wissen was für Vor- und Nachteile beide Varianten haben.

169

OS-Design / Re: GUI LowLevel

« am: 06. October 2011, 23:08 »

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

170

OS-Design / Re: GUI LowLevel

« am: 06. October 2011, 22:25 »

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).

171

OS-Design / Re: GUI LowLevel

« am: 06. October 2011, 21:32 »

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).

172

OS-Design / Re: GUI LowLevel

« am: 04. October 2011, 21:31 »

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).

173

OS-Design / Re: GUI LowLevel

« am: 04. October 2011, 10:43 »

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.

174

OS-Design / Re: GUI LowLevel

« am: 03. October 2011, 22:29 »

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.

175

OS-Design / Re: GUI LowLevel

« am: 03. October 2011, 15:06 »

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.

176

OS-Design / Re: GUI LowLevel

« am: 02. October 2011, 22:19 »

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.

177

OS-Design / Re: GUI LowLevel

« am: 02. October 2011, 16:03 »

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?

178

OS-Design / Re: GUI LowLevel

« am: 02. October 2011, 13:57 »

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).

179

OS-Design / Re: GUI LowLevel

« am: 01. October 2011, 15:42 »

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.

180

OS-Design / Re: GUI LowLevel

« am: 01. October 2011, 11:37 »

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 ) 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?