Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Nachrichten - FlashBurn

Seiten: 1 ... 8 9 [10] 11 12 ... 43
181
OS-Design / Re: GUI LowLevel
« am: 30. September 2011, 20:37 »
Zitat von: erik
Ich würde das so implementieren das die GUI der Anwendung mit dem Return-Wert einer Zeichen-Aktion immer mitteilt ob das gezeichnete überhaupt komplett oder nur zum Teil und gar nicht sichtbar ist (bei gar nicht eventuell noch nach Grund unterteilt: Verdeckt, Minimiert, Monitor-Aus, usw). Dann kann die Anwendung entscheiden ob es ihr wichtiger ist das sofort ein aktuelles Bild verfügbar ist wenn das Fenster wieder sichtbar wird oder ob lieber CPU-Leistung und Energie gespart werden sollen. Zusätzlich sollte die Anwendung der GUI auch mitteilen können über welche Veränderungen bei der Sichtbarkeit ihrer Fenster sie per Event (über den gleichen Mechanismus wie Tastendrücke und Maus-Events) benachrichtigt werden möchte, dann könnte die Anwendung wieder mit einer GIF-Animation weiter machen wenn der entsprechende Bereich wieder sichtbar ist.
Wieso muss sich die Anwendung um sowas kümmern? Das hat die GUI zu erledigen. Die Anwendung zeichnet neu wenn sie dazu aufgefordert wurde (was die Anwendung auch selbst tun kann).
Zumal willst du wirklich das eine Anwendung die Laufzeit deines Laptops beeinflusst, nur weil der Programmierer der Meinung war, das es so richtig wäre. Denn diese Methode heißt ja auch, dass die Anwendung das alle ignorieren kann (der Einfachheit wegen und weil es auf den meisten (allen?) anderen System auch so ist) und dann ist nix mehr mit Strom sparen.
Ich würde schon wollen das die GUI bestimmt, wer zeichnen darf und wer nicht.
182
OS-Design / Re: GUI LowLevel
« am: 29. September 2011, 22:38 »
Zitat von: erik
Nö, in meiner (sicherlich naiven) Vorstellung ist auch das verdeckte (oder verkleinerte) Fenster in der GUI immer komplett vorhanden (ja ich weiß dass das Speicher kostet) und kann daher sofort ohne mitwirken der Applikation dargestellt werden. Im Optimum sollten möglichst alle Fenster im Video-RAM der Grafikkarte vorhanden sein (und auch immer dort aktualisiert werden) so dass das verschieben von Fenstern nur das Ändern von ein paar Koordinaten im "Frame-Descriptor-Tree" ist und effektiv keine Pixel-Daten übertragen werden müssen (zumindest solange sich nicht auch wirklich Bildinhalt ändert).
Das wäre aber nicht mehr effizient. Denn du würdest zeichnen ohne das es Sinn macht. Wieso z.B. den Speicherbus mit einer GIF-Animation belasten, obwohl das Fenster nicht zu sehen ist und das für vllt ein paar Minuten?

Wenn ich mir überlege, was das auch an CPU Leistung kosten würde, wenn alle meine Tabs ständig am zeichnen wären bzw was sich da einsparen lässt. Anderes Bsp wäre wenn der Bildschirm aus wäre oder der Bildschirmschoner an wäre, da würden bei dir die Anwendungen alle schön weiterzeichnen. Auch ein blinkender Cursor muss nicht ständig aktualisiert werden, wenn das Fenster eh nicht zu sehen ist.

Ansonsten geht das auch mit Compositing. Nur das trotzdem nur gezeichnet wird, wenn auch nötig.

Zitat von: erik
Scrollen würde ich persönlich ganz anders machen. Ich würde das komplette Bild in den Video-Speicher laden und der Grafikkarte nur noch sagen "da liegt ein Bild mit den Ausmaßen X:Y an Offset Z im Video-RAM, zeichne davon den Teilausschnitt von U:V mit H:W ins Frame an A:B". Wenn gescrollt wird muss dann immer nur U:V angepasst werden und fertig. Ich persönlich empfinde es als arg eklig das ich im Browser immer solche hässlichen Ruckler sehen muss nur weil ich dort mal ein Bild mit ein paar mehr Megapixeln in 1:1 Darstellung umherscrolle. Sollte das Bild deutlcich größer sein als der Video-RAM es fassen kann dann muss es eben gekachelt werden, solange eine Kachel immer mindestens so groß ist wie die Darstellungsfläche im Fenster müssen auch nur mindestens 4 Kacheln im Video-RAM vorhanden sein (mehr schadet natürlich nicht um Rucklern beim weiterscrollen vorzubeugen). Heutzutage ist der Video-RAM deutlich größer als nötig wäre den Monitor-Inhalt mehr als 10 mal zu enthalten, stellt also alles kein Problem dar.
Das trifft auf den PC zu und Smartphones/Tablets sind auf dem besten Weg auch so viel RAM zu haben. Aber von der Rechenleistung her sollte es doch reichen, dass nicht alles in den RAM muss.

Ich habe heute erst wieder ein Spiel von 1999 in der Hand gehabt und die mind. Anforderungen lesen sich so, dass gerade mal 32MB RAM (unter Windows ab 95) benötigt werden und trotzdem war die Grafik für die damalige Zeit richtig gut.
Heute braucht man auch unter Linux, speziell darauf angepasste Versionen, damit mit so wenig RAM überhaupt ne GUI läuft. (Gut die Auflösungen haben sich auch geändert und das kostet ja auch Speicher, aber trotzdem :P)
183
OS-Design / Re: GUI LowLevel
« am: 29. September 2011, 19:34 »
Gut, dann sage doch mal was nen modernen Desktop modern macht (du denkst dabei doch an bestimmte Features oder?).

Auf meine Frage ob das Linux mit seinen Framebuffer-Devices nicht auch macht, hast du leider nicht geantwortet.
184
OS-Design / Re: GUI LowLevel
« am: 29. September 2011, 19:07 »
Zitat von: svenska
Fakt ist, mit dem VESA-Treiber machst du keinen Anwender glücklich. Entweder, du baust dir einen modernen Desktop - oder du lässt es sein.
Das würde ja heißen, dass alle Hobby-OSs keine GUIs haben dürfen, weil man einfach nicht für jede Graka nen Treiber haben kann.

Außerdem ist nen VESA-Treiber im Endeffekt nix anderes als nen Framebuffer-Device? Sowas wird doch auch ohne Probleme unter Linux eingesetzt.

Zitat von: svenska
Eine Mischung ist in jedem Fall Mist, und zwei Codepfade pflegen halte ich für unsinnig. Besonders bei so komplexem Zeug wie GUI und einem Hobby-OS.
Kann sein, dass ich zwecks nicht vorhandener Erfahrung, die ganze Sache gewaltig unterschätze, aber ich wollte es ja so machen, das die Anwendung der GUI sagt, welcher Bereich neugezeichnet werden muss und die GUI sendet dann ne Nachricht an die Anwendung das sie nen Redraw in einem Bestimmten Bereich machen soll. Diese Nachricht beinhaltet aber auch den Buffer wo die neuen Daten reinsollen.
Damit erreiche ich, das ich der Anwendung als Buffer einfach den Framebuffer der Graka geben kann oder den Framebuffer den ich im Systemram habe für den VESA-Treiber.
Auf jeden Fall merkt die Anwendung nix davon und der Aufwand für die GUI sollte sich auch in Grenzen halten oder übersehe ich da was?
185
OS-Design / Re: GUI LowLevel
« am: 29. September 2011, 18:12 »
Zitat von: svenska
Wenn die vorhandene Farbtiefe einen Alphakanal unterstützt (bei 32 Bit ist das möglich, sonst nicht), dann kann die Anwendung einen Teil ihres Fensters transparent machen und das Problem ist gelöst.
Problem ist, ich kann mir nicht vorstellen, das man das halbwegs effizient lösen kann. Denn dann müsste ich das oberste Fenster fragen, ob da wo sich die Maus befindet (und am besten gerade geklickt hat), das Fenster richtig ist oder nicht und wenn nicht, müsste ich zum nächst tieferen Fenster gehen usw.

Das muss sich doch auch anders lösen lassen.

Zitat von: svenska
Ansonsten bin ich grundsätzlich eher gegen Freiform-Fenster.
Naja, ich bin ja auch der Meinung nen Fenster kann ruhig ne rechteckige Form haben, aber da ich von dem BeOS/Haiku Design angetan bin (und das auch so umsetzen wollte), bräuchte ich halt sowas und da bietet sich dann an, dass die Anwendung nix mit Rahmen und Titelleiste zu tun hat.

Wenn ich mal die Lust dazu habe, versuche ich mal im Haiku-Source den Code dafür zu finden.

Zitat von: svenska
Ja. Aber zwei Systeme parallel zu unterstützen wäre mir zuviel Aufwand. Ich würde wahrscheinlich ausschließlich Compositing unterstützen, der VESA-Treiber hätte dann halt Pech und wäre etwas langsamer als notwendig.
Problem hierbei ist, würdest du dich wirklich damit abgeben, dass deine GUI dann auf den meisten System wahrscheinlich langsam bis zu langsam wäre (keine Ahnung wie groß der Unterschied ist)? Denn genügend Treiber wirst du wohl nicht zusammen bekommen, es sei denn du schaffst dir nen Layer, so dass du z.B. Linuxtreiber kompilieren und dann nutzen kannst (wie heißt die neue Schnittstelle für Grafiktreiber doch gleich, ich komm gerade nicht drauf?).
186
OS-Design / Re: GUI LowLevel
« am: 29. September 2011, 16:13 »
Zitat von: svenska
Davon rede ich die ganze Zeit.
Schön das wir uns verstehen :D

Ist es beim Theming auch möglich die Form der Fenster festzulegen? Oder anders, wie Schwierig wäre das, so schwierig das es sich wieder lohnen würde, die Anwendungen nur direkt ins Fenster zeichnen zu lassen und Rahmen und Titelleiste der GUI zu überlassen?

Zitat von: svenska
Nein, beide Systeme haben kein Compositing, wenn der VESA-Treiber verwendet wird...
Also können beide Compositing und die alte Variante (so wie ich es eigentlich auch geplant habe)?!

Zitat von: svenska
Es ist aber nicht Aufgabe des GUI-Systems, das nachträglich festzustellen, sondern Aufgabe der Anwendung, nur die entsprechenden Rechtecke zu übertragen. Ist jedenfalls meine Meinung.
Da hast du schon recht.

Man könnte das ja im VESA-Treiber machen. Der hat dann immer 2 Buffer mit dem Bildinhalt, einmal den mit dem vorherigen Bild und einmal den mit dem neuen Bild. So kann er dann vergleichen und nur das schreiben was sich wirklich geändert hat.

Solch eine Variante sollte man eigentlich sogar grundsätzlich machen, weil man will bestimmt nicht jedes Mal den Bereich vom Mauszeiger neuzeichnen lassen, indem man sich die Daten wieder von den Anwendungen holt, sondern dass man den Mauszeiger immer als letztes überträgt, aber nicht mit in den Buffern speichert.
187
OS-Design / Re: GUI LowLevel
« am: 29. September 2011, 15:19 »
Zitat von: svenska
Wenn die Titelleiste von der Anwendung gezeichnet wird und die Anwendung nicht auf Ereignisse reagiert, dann weiß die GUI wenigstens, wenn der Nutzer die Anwendung schließen möchte und kann sie z.B. töten.
Ich weiß gerade nicht wie Windows das macht, aber funktioniert das ja auch, wenn die Anwendung nicht reagiert, stellt Windows das irgendwie fest (vorallem wenn man dann ein paar Mal klickt) und fragt ob das Programm beendet werden soll.

Bei Theming kann man ja auch die Lage der Titelleistebuttons (schließen und sowas) ändern. Von daher wäre es eventuell ausreichend, wenn man Lage und Größe der 4 (unter Windows) Buttons (Systemmenü, Minimieren, Maximieren und Schließen) der GUI mitteilt.
Dann würde ich es aber so machen, dass es Grundsätzlich nur Fenster ohne Titelleiste und Rahmen gibt und dass das alles die Anwendung machen muss.

Zitat von: svenska
Es gibt Programme, für die ein anderes Aussehen durchaus sinnvoll ist (z.B. Spiele, die haben keine Titelleiste und der Schließen-Button ist im Hauptmenü).
Naja, dafür würde es dann doch 2 Typen von Fenster geben, einmal mit Rahmen und Titelleiste und einmal ohne Rahmen und Titelleiste.

Zitat von: svenska
Nicht unbedingt, aber wenn du ein modernes GUI-System haben willst, dann wird VESA nur suboptimal laufen und wenn du ein VESA-optimiertes GUI-System willst, dann kannst du Compositing direkt vergessen. Du hast die Wahl.
Windows und Linux haben auch noch VESA Treiber und beide nutzen Compositing. Zumal ich deswegen ja mit dem Gedanken spiele die GUI so zu entwerfen, dass zur Laufzeit entschieden wird, welche Variante (immer neuzeichnen direkt in den Framebuffer oder Compositing) genutzt wird.

Zitat von: svenska
Wozu vergleichen? Die Anwendung sagt dem GUI-System doch, was sich geändert hat. Die wird's schon wissen, nochmal extra einen Vergleichsschritt drüberzuwerfen ist überflüssig.
Es ging darum, dass das Schreiben in den Grakaspeicher nicht besonders schnell ist und das man deswegen so wenig Daten wie möglich zur Graka schicken sollte. Deswegen kam das mit dem Vergleichen und wirklich nur die Pixel senden die sich geändert haben.
Mit meinem Bsp. wollte ich darauf hinaus, das nur weil sich der Bereich des Buttons geändert hat, es noch lange nicht heißt das sich wirklich alle Pixel in dem Bereich geändert haben.

Anderes Bsp. du scrollst eine Webpage (z.B. das Forum) und das gesamte Fenster muss neugezeichnet werden. Bei den großen Flächen mit der gleichen Farbe, kannst du einiges an Bandbreite einsparen, indem du nur die Pixel schreibst, wo sich die Farbe auch verändert hat und bei diesem Bsp. wären das ne Menge Pixel die man nicht ändern müsste.
188
OS-Design / Re: GUI LowLevel
« am: 29. September 2011, 08:42 »
Zitat von: erik
Stell Dir einfach mal ein animiertes GIF vor (um z.B. eine kleine Fortschrittsanimation anzuzeigen), da könnte doch die Anwendung sich immer per Event antriggern lassen wenn mal wieder ein neues Bild gezeichnet werden muss (die Zeitabstände müssen bei GIF nicht immer gleich sein so das hier flexiblere Events erforderlich sein können) und die Anwendung dann eben einfach ein kleines Rechteck im Fenster mit einem neuen Bild füllen lässt. Wenn alle Bilder des GIFs bereits im Grafikspeicher liegen dann muss der GUI-Treiber nur noch immer einen Pointer austauschen, das würde ich als effizient bezeichnen. Von händischem Zeichnen halte ich auch nicht sehr viel.
Also irgendwann mussten ja die einzelnen Bilder des GIFs mal händisch gezeichnet werden um die Buffer anzulegen. Dann kommt noch hinzu, dass das was du beschreibst doch auch möglich ist, wenn die GUI die Anwendung antriggert. Denn es bleibt dabei, warum sollte man Buffer austauschen, wenn das Fenster gar nicht sichtbar ist.
Die Anwendung erstellt halt einfach ihre Buffer, speichert die meinetwegen in einer Liste, mit Zeitwerten und die Anwendung sendet zu jeder Zeit (wo sich der Inhalt ändert) eine Nachricht an die GUI, das sich was verändert hat und setzt den Zeiger auf das nächste Element in der Liste. Die GUI entscheidet jetzt aber, ob es Sinn macht einen neuen Buffer von der Anwendung anzufordern und nur dann wird auch ein Buffer übertragen. Das nenne ich effizient ;)

Zitat von: svenska
Die Idee, dass die Anwendung dem GUI-System mitteilt, wo die entsprechenden Buttons sitzen, finde ich garnicht so abwegig.
Welchen Vorteil hätte das? Ich sehe da nur mehr Aufwand in der GUI, der sonst in der Anwendung wäre.

Zitat von: svenska
Fakt ist, dass Anwendungen eigentlich alles über eine Library zeichnen, die entsprechende Funktionalität für Titelleisten usw. muss man nicht nochmal extra im GUI-System duplizieren. Theming ist ein Grund dafür, direktes Rendering auch - und insbesondere Spiele und Vollbildanwendungen wollen keine GUI-eigenen Titelleisten, sondern was eigenes.
Ich habe mich noch nicht mit solchen Libs beschäftigt, aber wie setzt man es dann um das alle Anwendungen gleich aussehen? Ich möchte eigentlich nicht, dass jede Anwendung ne andere Titelleiste (und damit wahrscheinlich auch noch andere Position der Buttons hat (schließen und sowas)) und andere Bedienelemente hat. Das sollte schon alles einheitlich sein.
Oder erreicht man das durch Theming?

Zitat von: svenska
Effektiv wird ein Großteil des heute irrelevanten Desktops weggelassen und soweit zurechtgestutzt, dass der Grafiktreiber eine Menge beschleunigen kann. Das setzt aber immer einen modernen Grafiktreiber voraus, VESA ist da nicht geeignet. Die Art und Weise, wie Windows 3.1x arbeitet, ist für solch primitive Hardware optimal - aber Theming, Compositing und große Buffer sind damit nicht sinnvoll möglich.
Naja, seien wir mal ehrlich, wer von uns rechnet schon damit, dass er nen hardwarebeschleunigten Grafiktreiber haben wird? Man wird immer irgendwie auf VESA zurück greifen müssen.
Deswegen wollte ich ja auch beide Varianten unterstützen.

Zitat von: svenska
Was sich geändert hat, weiß das GUI-System
Da bin ich mir gerade nicht so sicher. Sagen wir mal es wird ein Button gedrückt (und der Button wird dann gedrückt dargestellt), dann wird die GUI, von der Anwendung, zwar benachrichtigt dass sich der Bereich um den Button geändert hat, aber das heißt nicht, dass alle Pixel ne andere Farbe bekommen. Das bekommt man nur durch vergleichen heraus. In nem anderen Forum (osdev.org) wird halt empfohlen zu vergleichen (im Systemram) und nur die wirklich geänderten Werte an die Graka zu schicken, weil es sonst zu langsam ist.
189
OS-Design / Re: GUI LowLevel
« am: 28. September 2011, 20:25 »
Zitat von: erik
also mir persönlich gefällt das Konzept wo die Anwendung dazu aufgefordert wird Teile oder alles ihrer Fenster neu zu zeichnen absolut gar nicht.
Warum nicht?

Ich will das vorallem deswegen machen, weil es schön zu der Art und Weise des IPC passt. Denn es wird ja pro IPC Nachricht ein Thread erstellt, sprich der Thread ist nur vorhanden wenn auch wirklich was gemacht werden muss.
Zumal ich so ja erreichen will, dass die Anwendung auch wirklich nur aktiv wird, wenn sie was zeichnen muss (was sie ja nicht muss, wenn sie eh komplett verdeckt ist oder sich der geänderte Bereich in einem verdeckten Bereich befindet).

Zitat von: erik
Ich finde es sehr viel besser wenn die Anwendung einfach immer dann wenn sie der Meinung ist das tun zu müssen ihren Fensterinhalt aktualisiert.
Kann sie ja, wie oben beschrieben, machen. Sie muss nur einfach eine Nachricht mit dem Bereich an die GUI schicken und diese entscheidet ob das auch wirklich nötig ist oder auf einen späteren Zeitpunkt verschoben werden kann.

Zitat von: erik
Gerade das periodische händische Umkopieren des gesamten Framebuffers von einem SW-Buffer im normalen RAM in den Video-Speicher der Grafikkarte ist deutlich aufwendiger als wenn die Grafikkarte sich die Bilddaten selber per Busmastering aus dem Speicher holt.
Also man kopiert ja meistens nicht den gesamten Framebuffer (das will man ja gerade vermeiden), sondern nur das was sich geändert hat und dazu muss man auch lesen und das ist aus dem Grakaspeicher sehr langsam. Hat man Hardwarebeschleunigung nutzt man doch genau dafür BitBlt (das vergleicht doch und kopiert nur das was sich geänder hat, oder?).
190
OS-Design / Re: Locking innerhalb des Kernels
« am: 28. September 2011, 20:02 »
Zitat von: erik
Hm, das klingt umständlich, davon würde ich persönlich eher abraten.
Naja, Problem ist halt, es geht nicht ohne :(

Ich brauche die für die Idle-Threads, für das Killen von Threads/Tasks und für das Erstellen von Tasks.

Naja, was heißt umständlich. Ich stelle mir das dann so vor, dass ich alle Infos in Variablen sammle. Dann die Ints ausmache, den Speicher freigebe und was sonst noch gemacht werden muss.

Zitat von: erik
Neben dem VMM fällt mir da auch das Erstellen neuer (oder das Killen alter) Prozesse ein.
Interessant, dass immer diese beiden (erstellen und killen) Sachen genannt werden. Dabei bin ich mir sicher, dass das bei mir schneller ist als viele VMM aufrufe (wenn man nur eine Page mappen will, geht das klar schneller).
Ich habe das Erstellen und Killen halt in Threads ausgelagert (Kernelthreads) und weil die unterbrechbar sind (bzw. sein müssen) ist die Länge erstmal kein Problem, nur halt die Zugriffe auf den VMM und das ganz kurze Eintragen in Datenstrukturen.

Was ich vllt noch hätte zu den ticket locks schreiben sollen, sie schonen den Speicherbus (im Vergleich zur klassischen Spinlock). Aber auch sie sind nicht frei von Nachteilen und hier ist es das Cachesystem.
Der Vorteil ist ja, das pro Zugriff (also Lock bekommen und wieder freigeben), nur ein einziger lock Befehl ausgeführt werden muss. Das Spinnen findet dann im Cache statt.
Das ganze kann man auch noch entschärfen, aber mit mMn viel zu viel Speicheraufwand (Array von ticket locks und ein Element ist immer so groß wie eine Cacheline).

Ich habe heute auch alle meine Spinlocks durch diese ticket locks ersetzt und dadurch das ich mich auch nicht mehr um die Ints kümmern muss, ist der Code deutlich geschrumpft.

Ein Problem bleibt, aber trotzdem noch mit einem nicht unterbrechbaren Kernel. Die Locks werden dort nämlich noch teurer als bei einem Unterbrechbaren Kernel. Denn es kann passieren das alle CPUs gleichzeitig auf einen Lock zugreifen wollen und die letzte CPU muss dann sehr lange warten (abhängig von der Anzahl der CPUs und der Länge des kritischen Bereichs).
Entschärft wird das dadurch, dass die ersten CPUs ja theoretisch genügend Zeit haben einen IRQ entgegen zu nehmen, aber da kommt dann auch schon wieder ein anderes Problem. Soweit mir bekannt, kann man den IO-APIC ja so programmieren, dass immer die CPU den IRQ bekommt, die die niedrigste Priorität hat, aber wenn diese gerade die Ints aus hat, wird der IRQ auch nicht an eine andere CPU weitergegeben. Sprich wenn nun dummerweise die letzte CPU (aus obigem Beispiel) den IRQ bekommt, kann es auf Systemen mit vielen Cores doch wieder zu unschönen Latenzen kommen (von SingelCore gar nicht zu sprechen).
191
OS-Design / Re: Locking innerhalb des Kernels
« am: 28. September 2011, 10:36 »
Nachdem ich erst jetzt auf diese Art von spinlock aufmerksam geworden bin, vielleicht ist ja für den ein oder anderen ein ticket lock interssant, weil es nen fairer Lock ist.

Ich bin jetzt dann soweit meinen Kernel doch so zu gestalten das er nicht unterbrechbar ist, aber das ich trotzdem Kernel-Threads habe, welche ja unterbrechbar sein müssen. Dort müsste ich die Ints per Hand an und aus machen.
Das eignet sich natürlich nicht für nen Monolith, sondern nur für nen Mikrokernel, der halbwegs kurze Funktionen hat (Problem bei mir ist der VMM, der im worst-case schon mal ne Weile brauchen kann).
192
OS-Design / Re: GUI LowLevel
« am: 27. September 2011, 20:24 »
Zitat von: porkchicken
Funktioniert unter Windows mehr oder weniger so, wie du beschrieben hast. ...
Interessant das es unter Windows so gemacht wird, nur wird es dann nicht wirklich asynchron umgesetzt. Denn wenn eine Anwendung durch irgendeinen CPU intensiven Prozess blockiert ist, wird die GUI nicht neu gezeichnet und nimmt auch keine Befehle mehr entgegen. Das wollte ich halt voneinander trennen, so dass sowas nicht passieren kann.

Zitat von: porkchicken
Unter Windows wird der Anwendung eine andere Nachricht (WM_NCPAINT, NC = Non-Client Area) geschickt, wenn der Rahmen, usw. neugezeichnet werden muss. Die Anwendung kann dann einen anderen Device Context anfordern, mit dem sie außer halb des Fensters rummalen kann.
Also ich würde das nicht so zulassen. Wenn die Anwendung wirklich alles (inkl. Titelleiste und Rahmen) selbst zeichnen will, dann sollte sie das schon von Anfang an wissen und dem entsprechend ein Fenster ohne Titelleiste und Rahmen erzeugen.

Welchen Grund hat ein Programm außerhalb des eigenen Fensters zu zeichnen?

Das man unter Windows einen Device Context anfordern muss (was ich jetzt mal mit nem Buffer gleichsetze) wäre in meinem Design auch von Vorteil. Ich überlege nämlich noch, ob ich einmal die Variante des direkten Schreibens in den Framebuffer und des jedes Fenster seinen eigenen Buffer hat unterstütze, so dass auf Systemen mit zu wenig Speicher (keine Ahnung woran ich das dann festmachen würde) die GUI trotzdem laufen würde. Ist wie mit dem Caching, wenn genug Speicher vorhanden ist wird dieser fürs Caching genutzt.
Dadurch dass das Fenster nen Buffer vom GUI bekommt, merkt das Fenster den Unterschied auch gar nicht.
193
OS-Design / Re: GUI LowLevel
« am: 27. September 2011, 19:11 »
Zitat von: svenska
Ich würde vorschlagen, jedes Fenster kriegt einen eigenen Buffer von der GUI zugeteilt und wenn sich darin etwas geändert hat, wird die GUI über den geänderten Bereich informiert.
Ich dachte da, in meiner naiven Art ;), daran asynchron zu zeichen. Soll heißen dass das Programm etwas neu zeichnen möchte und das sagt sie der GUI (mit dem entsprechendem Bereich) und die GUI entscheidet dann ob der Bereich sichtbar ist oder nicht und wenn er sichtbar ist, wird eine Nachricht an die Anwendung geschickt, dass sie einen bestimmten Bereich neu zeichnen soll. Das hätte halt den Vorteil, das wirklich nur gezeichnet wird, wenn das auch nötig ist.
Die Frage ist jetzt, kann das überhaupt so funktionieren?

Zitat von: svenska
Schnell und CPU-sparsam wird das nur, wenn du genug Grafikspeicher hast, um diese Buffer dort zu lagern (du die also nicht über den Bus schicken musst)
Das verstehe ich nicht ganz, da die Anwendung den Buffer ja mit Daten füllen muss, muss ja auf jeden Fall was über den Bus geschickt werden. Zumal gilt nicht noch immer dass das Schreiben in den Grafikspeicher nicht alzu schnell ist, sprich das es sich lohnt bei Doublebuffering einen Buffer (das fertige Bild) im Systemspeicher zu haben und diesen Buffer dann per BitBlt (oder halt kopieren) an die Grafikkarte zu schicken?

Zitat von: svenska
Steuerelemente und Dekorationen sind Anwendungssache
Naja, ich dachte da dann schon an eine Lib die so die Standardsteuerelemente (was meinst du mit Dekorationen?) beinhaltet.

Zitat von: svenska
(es sei denn, du lässt die Titelleiste vom Window Manager zeichnen)
Soll heißen, die Anwendung "sieht" die Titelleiste gar nicht in ihrem Buffer? Mal davon abgesehen, das ich die Idee verlockend finde (würde das was mir vorschwebt bestimmt einfacher machen), wie wird dort dann Theming umgesetzt, da das ja dann an zwei unterschiedlichen Stellen stattfinden müsste?

Zitat von: svenska
Neben BitBlit gibt es aber noch Muster, Linien, Kreise, Ellipsen usw. die hardwarebeschleunigt sein können.
Das war eigentlich das was ich meinte, mit das man der Grafikkarte sagen konnte, das man ein Rechteck zeichnen möchte.

Wie verhält es sich eigentlich mit FreeForm Windows und dem Feststellen was neu gezeichnet werden muss? Da kann ich ja schlecht nen Recheck für nehmen und jedes Mal zeichnen lassen (wenn man jetzt mal davon ausgeht, das es keine Buffer pro Fenster gibt) nur um festzustellen dass das Fenster dort nix zeichnet, ist ja auch doof. Geht das nur halbwegs effektiv mit nem Buffer pro Fenster (so dass man nen Farbwert festlegt, wo dann kein Zeichenbereich ist)?
194
OS-Design / GUI LowLevel
« am: 27. September 2011, 14:32 »
Ich wollte mich gedanklich mal mit den LowLevel Konzepten einer GUI vertraut machen.

Erstmal was ich unter LowLevel verstehe. Damit meine ich wie was wann gezeichnet wird.

Hat wer dazu ein paar interessante Links/Papers die man lesen kann/sollte?

Ich "kenne" bisher folgende Konzepte:

Es wird direkt ein Bild im Grafikkartenspeicher erzeugt, sprich die einzelnen Programme haben keinen eigenen Buffer (sofern sie sich selbst keinen Anlegen), sondern bekommen von der GUI gesagt das sie doch bitte neuzeichnen sollen und welchen Bereich. Dort sollte doch der Buffer in den sie schreiben, auch mit übergeben werden und nicht so dass das Programm in einen eigenen Buffer schreibt und den dann an die GUI schickt, oder?
Das sollte so die "alte" Variante sein und vorallem die am wenigsten Speicher verbraucht, weil ja immer nur direkt in den Framebuffer geschrieben wird. Allerdings verbraucht dies auch mehr CPU Zeit.

Zu dieser Variante hätte ich gleich mal Fragen.

Ist das die Variante wie sie unter alten GUIs verwendet wurde (z.B. Windows 3.11)? Wenn ja, wie haben die Auflösungen wie 1024x768x32bit hinbekommen? Damit meine ich das wenn man davon ausgeht, dass das gesamte Bild neugezeichnet werden muss und von einem PCI-Bus ausgeht (was ja nicht unbedingt sein musste), wie konnten die 60Hz (FPS) und mehr erreichen? Das geht doch schon aus Bandbreitengründen nicht. Bei einem ISA-Bus und 640x480x32bit sollte das ja eigentlich auch nicht gehen.
Oder wurde früher einfach nur 16bit oder sogar nur 256 Farben verwendet?

Die andere Variante die ich dann kenne, nennt sich wohl Compositing (??).

Dort hat jedes Programm einen Buffer von seinem Fenster(n) und wenn die GUI ein neues Bild zeichnen möchte (und sich etwas in diesem Fenster geändert hat), erstellt das Programm nen neuen Buffer, zeichnet dort rein und schickt den Buffer an die GUI.
Vorteil ist hier das weniger CPU Zeit, aber dafür wesentlich mehr Speicher verbraucht wird.
Soweit richtig?

Was mich jetzt, insbesondere wenn ich dann irgendwann mal ne GUI designen möchte, interessiert, wie kann man dort Theming umsetzen bzw. wie wird es gemacht das jedes Fenster und die Komponenten gleich aussehen?

Ich stelle mir das so vor, dass man OS Libs nutzt um die Fenster und Elemente zu zeichnen und nicht nur in das eigentliche Fenster (ohne Rahmen, Menüleiste und sowas), sondern immer das gesamte Fenster (halt mir Rahmen, Menüleiste und sowas) zeichnet.
Theming würde dann so funktionieren, dass sich die Libs halt die Daten aus irgendwelchen Dateien holen, wie nun die Titelleiste aussehen soll, wie der Rahmen aussehen soll usw.
Ist das auch soweit richtig?

Dann, auch wenn es eigentlich außerhalb dessen liegt was ich je erreichen werde, wie läuft das mit 2D Hardwarebeschleunigung? Soweit ich es verstanden habe, gibt es die nur soweit das man Blitting in irgendeiner Weise hardwarebeschleunigt zur Verfügung hat.
Allerdings entsinne ich mich mal was gelesen zu haben, dass früher auch primitive Objekte (ala Rechteck und sowas) per Grafikkartenbefehl gezeichnet wurden?! Kann es sein, dass so höhere Auflösungen und Bittiefen möglich waren?

195
Softwareentwicklung / Re: GCC 4.6.0 ELF Sektionen und Symbole
« am: 25. September 2011, 11:09 »
Ich habe mir jetzt mal nen Linkersckript zusammengebastelt und bin die ".group" Sektionen los, wollte aber gleich auch die Konstruktoren für die globalen statischen Objekte mit reinnehmen, so dass sie automatisch ausgeführt werden (von meinem Code natürlich).

Aber die tauchen aus irgendeinem Grund nicht mehr in der endgültigen Objektdatei auf, in der speziellen Objektdatei schon (die Objektdatei zu der jeweiligen .cpp Datei).

SECTIONS
{
.init ALIGN(4) :
{
start_ctors = .;
*(.ctors*)
end_ctors = .;

*(.init*)
*(.text.startup*)
}

.text ALIGN(4) :
{
*(.text*)
}

.rodata ALIGN(4) :
{
*(.rodata*)
}

.data ALIGN(4) :
{
*(.data*)
}

.bss ALIGN(4) :
{
*(.bss*)
}

/DISCARD/ :
{
*(.comment)
*(.dtors*)
*(.group*)
*(.text.exit*)
}
}

Ist an dem Skript irgendwas falsch oder was könnte es noch sein, das die Konstruktoren weg sind (start_ctors und end_ctors haben die gleiche Adresse)?

Edit::

Also das Problem liegt in meinem Bootloader und nicht am Skript. Ich trage die Symbole mit der richtigen Adresse in meinen PatriciaTree ein, aber wenn ich dann alle Symbole auflöse (Relocation), bekommt ich ne falsche und die gleiche Adresse für die beiden Symbole (start_ctors und end_ctors). Was irgendwie komisch daran ist, der Kernel scheint ansonsten trotzdem zu laufen, also scheinen die anderen Symbole alle richtig aufgelöst zu werden.

Edit::

Problem gelöst :D

War eigentlich ziemlich "einfach", da ich im Bootloader mehrere Module zusammenlinke, die ja alle die beiden Symbole (start_ctors und end_ctors) haben, kann es nur schief gehen, weil die ja alle andere Adressen haben.
Ich habe es jetzt so gelöst, dass ich diese Symbole nicht mehr im Linkerskript erzeuge, sondern das der Bootloader sich den Anfang und das Ende der allgemeinen ctors Sektion (wo alle .ctors aus allen Modulen reinkommen) merkt und die Adressen für die Symbole (start_ctors und end_ctors) einfach in meinen PatriciaTree einfügt. Damit werden jetzt auch endlich die globalen statischen Konstruktoren aufgerufen und ich muss das nicht mehr von Hand machen.
196
Softwareentwicklung / Re: GCC 4.6.0 ELF Sektionen und Symbole
« am: 24. September 2011, 13:58 »
Ich grabe den Thread mal wieder aus, da die ".group" Sektionen wieder da sind :(

Sie treten nur auf, wenn ich pure virtual Methoden (kann auch nur virtual sein, da bin ich mir nicht sicher, weil ich es nicht verwende) oder Templates nutze.

Es ist nicht das Problem das ich diese Dateien nicht verarbeiten könnte, aber es ist halt Speicherverschwendung und setzt damit effektiv mein Cachesystem im Bootloader außer Kraft.
Von daher würde ich diese Sektionen gerne loswerden und ich würde auch die vielen unter-Sektionen gerne zusammenfassen.

Eigentlich müsste das doch mit nem Linker-Skript gehen oder (ich will keine executeable, sondern eine Objektdatei erzeugen!)?

Ich habe dann noch solch nette ".text.startup" Sektionen. Wozu sind die gut (ich vermute mal sie haben was mit den globalen statischen Objekten zu tun)? Das gleiche dann nochmal zu ".text.exit", wird wahrscheinlich für die globalen statischen Objekte sein.
Auch interessant sind die read-only Sektionen für meine abgeleiteten Klassen, wo dann die virtuellen Methoden implementiert werden. Eine Sektion für die Basisklasse, mit 2 Relokationen für die __cxa_pure_virtual Funktion und dann noch jeweils eine Sektion für jede abgeleitete Klasse mit auch 2 Relokationen für die beiden implementierten Funktionen.
Wie muss ich mir das dann vorstellen, hat jedes Objekt nen Pointer zu diesen Sektionen damit, der Code weiß, welche Funktion er aufrufen muss?
197
Mich interessiert es ;)

Und wenn du einmal dabei bist, könntest du ja zu noch einem ähnlichen Thema deine Meinung/Wissen äußern.

RISC vs. CISC

Also ich würde mal sagen, das RISC alleine schon wegen einer geringeren Komplexität stromsparender gemacht werden kann, da sind wir uns einig. Was aber die Performance betrifft, kann es sein, das da CISC durch aus im Vorteil ist oder würde RISC bei gleicher Performance (und da meine ich auf aktueller Core-i Ebene) und selben Features (64bit, SIMD) deutlich weniger verbrauchen?
Im Endeffekt geht es mir genauer darum, wo die Vorteile eines festen Opcode Formats (sprich feste Befehlslänge) gegenüber eines dynamischen Opcode Formats (sprich dynamische Befehlslänge) liegen (und natürlich auch die Nachteile).
198
OS-Design / Re:Optimale Baumstrukturen fuer malloc/free
« am: 06. September 2011, 09:47 »
Zitat von: rizor
Naja, du als Entwickler bist dazu verpflichtet dich über die Patentlage zu informieren.
Das ist schon klar, aber halt unrealistisch. Genauso wie bei unserem Steuerrecht. Nicht mal das Finanzamt kennt sich da wirklich aus, aber der dumme durchschnitts Bürger soll sich auskennen.
199
OS-Design / Re:Optimale Baumstrukturen fuer malloc/free
« am: 06. September 2011, 09:35 »
Zumal es unrealistisch ist, dass jemand alle Patente aus allen Ländern kennt (was ja auch die rechtliche Situation mit betrifft). Ich wette sogar, dass man dafür mehr als nur einen Anwalt braucht um sowas weltweit prüfen zu lassen und damit wären eigentlich alle kleinen "Firmen" raus, weil die sich das gar nicht leisten können.
200
OS-Design / Re:Optimale Baumstrukturen fuer malloc/free
« am: 06. September 2011, 08:47 »
Zitat von: rizor
Das Problem besteht bei allen Projekten, die irgendwie in den USA vertreten sind.
Wenn nur etwas Code davon in die Staaten kommt, könnte der Programmierer bei der Einreise Probleme bekommen.
Daran dachte ich zwar auch, aber dann gilt das für alles was im Internet ist oder?
Seiten: 1 ... 8 9 [10] 11 12 ... 43

Einloggen