Thema: GUI LowLevel

[FlashBurn]

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.

[Svenska]

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

[FlashBurn]

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.

[Svenska]

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?

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

[FlashBurn]

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

[erik.vikinger]

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

[FlashBurn]

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

[kevin]

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.

[FlashBurn]

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

[erik.vikinger]

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

[erik.vikinger]

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

[FlashBurn]

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

[kevin]

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?

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.

[erik.vikinger]

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.

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

[kevin]

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.

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.

[erik.vikinger]

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

[FlashBurn]

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?

[erik.vikinger]

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

[FlashBurn]

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

[Svenska]

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.