Thema: GUI LowLevel

[FlashBurn]

Fakt ist, mit dem VESA-Treiber machst du keinen Anwender glücklich. Entweder, du baust dir einen modernen Desktop - oder du lässt es sein.

Das würde ja heißen, dass alle Hobby-OSs keine GUIs haben dürfen, weil man einfach nicht für jede Graka nen Treiber haben kann.

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

Eine Mischung ist in jedem Fall Mist, und zwei Codepfade pflegen halte ich für unsinnig. Besonders bei so komplexem Zeug wie GUI und einem Hobby-OS.

Kann sein, dass ich zwecks nicht vorhandener Erfahrung, die ganze Sache gewaltig unterschätze, aber ich wollte es ja so machen, das die Anwendung der GUI sagt, welcher Bereich neugezeichnet werden muss und die GUI sendet dann ne Nachricht an die Anwendung das sie nen Redraw in einem Bestimmten Bereich machen soll. Diese Nachricht beinhaltet aber auch den Buffer wo die neuen Daten reinsollen.
Damit erreiche ich, das ich der Anwendung als Buffer einfach den Framebuffer der Graka geben kann oder den Framebuffer den ich im Systemram habe für den VESA-Treiber.
Auf jeden Fall merkt die Anwendung nix davon und der Aufwand für die GUI sollte sich auch in Grenzen halten oder übersehe ich da was?

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

Hervorhebung von mir.

[FlashBurn]

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.

[erik.vikinger]

Hallo,

Naja, seien wir mal ehrlich, wer von uns rechnet schon damit, dass er nen hardwarebeschleunigten Grafiktreiber haben wird?

Also ich rechne schon damit, zumindest das zusammensetzen des gesamten Frames auf vielen kleinen unabhängigen und flexiblen Rechtecken möchte ich schon in HW unterstützen (also HW-beschleunigtes 2D, ausreichend Video-RAM sollte ja bei den heutigen bzw. zukünftigen Preisen für DRAM-Chips kein Problem darstellen). Falls ich an meiner Plattform mal mehr haben will als eine Konsole per RS232 dann muss ich mich eh nach geeigneten Grafikkontrollern umsehen, ich hab da auch schon mal einen sehr interessanten Kandidaten gefunden der eigentlich alles kann was mir vorschwebt und für den es auch vollständige Datenblätter gibt.

also mir persönlich gefällt das Konzept wo die Anwendung dazu aufgefordert wird Teile oder alles ihrer Fenster neu zu zeichnen absolut gar nicht.

Naja, wenn ich ein Fenster verschiebe, dann muss das Fenster, was da vorher (teilweise) hinter gelegen hat, davon erfahren und den Teil, der gerade freigelegt wurde, neu zeichnen.

Nö, in meiner (sicherlich naiven) Vorstellung ist auch das verdeckte (oder verkleinerte) Fenster in der GUI immer komplett vorhanden (ja ich weiß dass das Speicher kostet) und kann daher sofort ohne mitwirken der Applikation dargestellt werden. Im Optimum sollten möglichst alle Fenster im Video-RAM der Grafikkarte vorhanden sein (und auch immer dort aktualisiert werden) so dass das verschieben von Fenstern nur das Ändern von ein paar Koordinaten im "Frame-Descriptor-Tree" ist und effektiv keine Pixel-Daten übertragen werden müssen (zumindest solange sich nicht auch wirklich Bildinhalt ändert). Klar wäre es doof wenn man plötzlich mit HW konfrontiert ist die das nicht beherrscht und man dann alles das aufwendig in SW nachbilden muss aber irgendwo muss man IMHO eine untere Schwelle ansetzen und das was mir vorschwebt sollte eigentlich seit 10 Jahren keinen käuflich erwerbbaren (PCI/PCIe-)Grafikkontroller vor erhebliche Hindernisse stellen. Selbst teil-transparente Fenster stellen in dem System kein Problem dar (von der zusätzlichen Speicherbandbreite im Video-RAM fürs mehrfache Lesen pro Pixel mal abgesehen).

Was du vorschlägst, ist Compositing.

Ganz genau, das will ich.

Die Idee, dass die Anwendung dem GUI-System mitteilt, wo die entsprechenden Buttons sitzen, finde ich garnicht so abwegig.

Ja, dem kann ich zustimmen. Wenn man Fenster ohne Dekoration anbieten möchte (und ich denke das ist für eine GUI Pflicht und bei einer entsprechenden GUI-Library eventuell sogar die Regel) dann muss es da zumindest ein paar grundlegende Bedienelemente geben die immer funktionieren.

Guck dir das X11-Protokoll an und sage mir, ob du das gut findest.

Ich hab mir X11 vor etlichen Jahren nur mal kurz und nur recht oberflächlich angesehen. Vom Konzept her ist das wimre gar nicht mal so verkehrt wenn wohl auch die Umsetzung nicht mehr so ganz Zeitgemäß ist.

Eine Anwendung, die mit GTK oder Qt geschrieben ist, braucht die Funktionalität, die GTK oder Qt bieten, nicht nochmal extra aus dem GUI-System benutzen. Von daher sehe ich keinen wirklichen Rückschritt.

GTK und Qt machen eigentlich alles in SW und liefern an die GUI nur noch ein fertiges Bitmap, genau das finde ich persönlich eher ungeschickt und von der Performance her auch suboptimal. Ich behaupte mal mit einer passenden HW-Unterstützung und der Fähigkeit von der Grafik-Library diese Möglichkeiten auch durch das GUI-System hindurch effizient nutzen zu können sollte man einen schicken und modernen KDE-Desktop auch mit nem 100 MHz Pentium noch flüssig bedienbar machen können.

Wer redet denn von synchronem IPC? Grafische Nutzeroberflächen sind asynchron.

Hm, stimmt. Aber wie ich den Bild-Speicher von den Anwendungen in die GUI bekomme ohne dafür die Anwendungen länger als nötig zu blockieren und ohne kopieren zu müssen hab ich mir auch noch nicht überlegt.

Hier wäre es noch cool wenn die Anwendung das erneute Zustellen von Bedien-Events erst wieder freischalten muss und vorher sämtliche Mausklicks und Tastendrücke einfach nur ins leere gehen

Dagegen. Events vom Benutzer wegwerfen ist immer falsch. Wenn ich ein Fenster anklicke, was gerade beschäftigt ist, dann will ich nicht, dass ich ignoriert werde.

Gut, auch wieder wahr, den Svenska zu ignorieren wäre einfach unhöflich. Ich denke man merkt schon deutlich das ich von GUI noch nicht sonderlich viel Ahnung hab, vielleicht sollte ich dieses Thema auch erst mal da lassen wo es für mich momentan eigentlich hin gehört, ganz hinten.

In Windows sind die meisten Steuerelemente als Fenster realisiert, sie sehen nur nicht so aus.

Das kenne ich von Swing auch, da wurde fast alles von JPane (ich hoffe mein Gedächtnis lässt mich da jetzt nicht im Stich) abgeleitet. So eine JPane kann entweder eigenen Bild-Inhalt haben oder eine/mehrere JPane wieder als Unter-Elemente beherbergen.

Stell Dir einfach mal ein animiertes GIF vor (um z.B. eine kleine Fortschrittsanimation anzuzeigen), da könnte doch die Anwendung sich immer per Event antriggern lassen

Das betrachte ich als vom Design her kaputt.

Ich glaube da hast Du mich missverstanden. Ich meine das die Anwendung sich z.B. von einem System-Timer regelmäßig antriggern lassen kann, sowas soll nicht Aufgabe der GUI sein, um dann den Bildinhalt bei der GUI zu aktualisieren (also neu zeichnen), eben je nach dem was für das entsprechende darzustellende Objekt erforderlich ist. Für richtige Videos sollte natürlich auch ne spezial-API vorhanden sein, obwohl ich schon der Meinung bin das das grundsätzlich auch ohne spezial-API möglich sein sollte solange die RAM-Performance und auch die PCI-Performance dabei gut mitspielen (was heute selbst für Full-HD als gegeben zu betrachten ist). Wenn Du das immer noch als "kaputt" betrachtest dann erkläre mir das Bitte mal.

Anderes Bsp. du scrollst eine Webpage (z.B. das Forum) und das gesamte Fenster muss neugezeichnet werden. Bei den großen Flächen mit der gleichen Farbe, kannst du einiges an Bandbreite einsparen, indem du nur die Pixel schreibst, wo sich die Farbe auch verändert hat und bei diesem Bsp. wären das ne Menge Pixel die man nicht ändern müsste.

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

Wenn die vorhandene Farbtiefe einen Alphakanal unterstützt (bei 32 Bit ist das möglich, sonst nicht), dann kann die Anwendung einen Teil ihres Fensters transparent machen und das Problem ist gelöst.

Problem ist, ich kann mir nicht vorstellen, das man das halbwegs effizient lösen kann. Denn dann müsste ich das oberste Fenster fragen, ob da wo sich die Maus befindet (und am besten gerade geklickt hat), das Fenster richtig ist oder nicht und wenn nicht, müsste ich zum nächst tieferen Fenster gehen usw.

Das muss sich doch auch anders lösen lassen.

Aber so wird das gemacht. Die GUI sendet den Event an das oberste Fenster und dieses behandelt den entweder selber oder gibt ihn der GUI zurück mit der klaren Info den eine Ebene tiefer zu reichen, anders kann man das mMn nicht lösen.

Gut, dann sage doch mal was nen modernen Desktop modern macht (du denkst dabei doch an bestimmte Features oder?).

Für mich persönlich wäre z.B. wichtig das ein Video weiter läuft auch wenn ich das entsprechende Fenster verschiebe und zwar ohne hässliche Artefakte (sowas wie das in dem Bereich wo das Fenster hingeschoben wurde nicht gleich das Video zu sehen ist oder das die Fenster(-Bereiche) die zum Vorschein kommen Weiße Flächen sind). Das alles sollte eigentlich schon seit über 10 Jahren nicht mehr auftreten, die HW kann das auf jeden Fall, es mangelt meiner Meinung nach nur an geeigneter Software.


Grüße
Erik

[FlashBurn]

Nö, in meiner (sicherlich naiven) Vorstellung ist auch das verdeckte (oder verkleinerte) Fenster in der GUI immer komplett vorhanden (ja ich weiß dass das Speicher kostet) und kann daher sofort ohne mitwirken der Applikation dargestellt werden. Im Optimum sollten möglichst alle Fenster im Video-RAM der Grafikkarte vorhanden sein (und auch immer dort aktualisiert werden) so dass das verschieben von Fenstern nur das Ändern von ein paar Koordinaten im "Frame-Descriptor-Tree" ist und effektiv keine Pixel-Daten übertragen werden müssen (zumindest solange sich nicht auch wirklich Bildinhalt ändert).

Das wäre aber nicht mehr effizient. Denn du würdest zeichnen ohne das es Sinn macht. Wieso z.B. den Speicherbus mit einer GIF-Animation belasten, obwohl das Fenster nicht zu sehen ist und das für vllt ein paar Minuten?

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

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

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

Das trifft auf den PC zu und Smartphones/Tablets sind auf dem besten Weg auch so viel RAM zu haben. Aber von der Rechenleistung her sollte es doch reichen, dass nicht alles in den RAM muss.

Ich habe heute erst wieder ein Spiel von 1999 in der Hand gehabt und die mind. Anforderungen lesen sich so, dass gerade mal 32MB RAM (unter Windows ab 95) benötigt werden und trotzdem war die Grafik für die damalige Zeit richtig gut.
Heute braucht man auch unter Linux, speziell darauf angepasste Versionen, damit mit so wenig RAM überhaupt ne GUI läuft. (Gut die Auflösungen haben sich auch geändert und das kostet ja auch Speicher, aber trotzdem )

[erik.vikinger]

Hallo,

Das wäre aber nicht mehr effizient. Denn du würdest zeichnen ohne das es Sinn macht. Wieso z.B. den Speicherbus mit einer GIF-Animation belasten, obwohl das Fenster nicht zu sehen ist und das für vllt ein paar Minuten?

Deswegen ja das :

Das eine Anwendung wissen können sollte ob ihr Fenster überhaupt sichtbar ist ist aber auch wieder richtig. Sie könnte der GUI ja sagen das sie benachrichtigt werden möchte wenn ihr Fenster wieder sichtbar ist (selbst wenn nur zum Teil), ....

Ich würde das so implementieren das die GUI der Anwendung mit dem Return-Wert einer Zeichen-Aktion immer mitteilt ob das gezeichnete überhaupt komplett oder nur zum Teil und gar nicht sichtbar ist (bei gar nicht eventuell noch nach Grund unterteilt: Verdeckt, Minimiert, Monitor-Aus, usw). Dann kann die Anwendung entscheiden ob es ihr wichtiger ist das sofort ein aktuelles Bild verfügbar ist wenn das Fenster wieder sichtbar wird oder ob lieber CPU-Leistung und Energie gespart werden sollen. Zusätzlich sollte die Anwendung der GUI auch mitteilen können über welche Veränderungen bei der Sichtbarkeit ihrer Fenster sie per Event (über den gleichen Mechanismus wie Tastendrücke und Maus-Events) benachrichtigt werden möchte, dann könnte die Anwendung wieder mit einer GIF-Animation weiter machen wenn der entsprechende Bereich wieder sichtbar ist.


Grüße
Erik

[FlashBurn]

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.

[erik.vikinger]

Hallo,

Ich würde schon wollen das die GUI bestimmt, wer zeichnen darf und wer nicht.

Hm, interessante Meinung, vor allem im Hinblick auf diese Aussage :

(was die Anwendung auch selbst tun kann).

Ich denke mal ein GUI wird immer beide Wege anbieten müssen. Mein Vorschlag unterscheidet sich nur etwas in der Umsetzung aber die grundsätzlichen Möglichkeiten sind genauso vorhanden wie in allen anderen GUI-Systemen auch. Die GUI wird die Anwendung üblicherweise nur bei externen Events oder Veränderungen in der Sichtbarkeit (was auch externe Events sind) antriggern neu zu zeichnen, das kann mein Vorschlaug auch indem der Anwendung einfach gesagt wird "Dein Fenster ist sichtbar, male das mal neu" und die Anwendung kann das sofort, nachher oder auch gar nicht tun (je nach Lust und Laune), mir ist dabei nur wichtig das die GUI ansich noch voll funktioniert und nicht blockiert o.ä. Ebenso muss es auch immer eine Möglichkeit geben das die Anwendung von sich aus neu zeichnet, sonst wären Animationen oder z.B. Fortschrittsbalken gar nicht möglich. Das einzigste was ich anders machen möchte ist das bei mir die zweite Variante der Standard-Fall ist. Bei Animationen o.ä., also den Dingen wo die Anwendung von sich aus regelmäßig neu zeichnet, sollte die Anwendung eh Dinge wie die Sichtbarkeit des Fensters berücksichtigen um eben nicht unnütz Energie zu verschwenden, das muss die Anwendung aber in beiden Varianten auf jeweils ähnliche Weise tun.
Ich sehe nicht wo meine Idee schlechter sein sollte als der übliche Weg. Ich bin eher der Meinung das meine Idee mehr Flexibilität bringt weil die GUI unabhängiger ist (was leider u.a. mit einem deutlich höherem Speicherverbrauch einhergeht aber damit kann ich gut leben).

Die einzigste Möglichkeit die ich sehe Animationen u.ä. mit absolut maximaler Effizienz (im Bezug auf Energie-Verbrauch und auf CPU-Zeit-Verbrauch) zu ermöglichen ist wenn die GUI die Animationen gleich selber erledigt. Man könnte ja der GUI einfach sagen "ich hab da eine Pane und in die legst Du mir Bitte dieses GIF rein und lässt das ab dem Zeitpunkt X laufen", dann hätte die GUI volle Kontrolle darüber und bräuchte auch nicht die Anwendung wenn das Fenster wieder sichtbar wird oder sowas. Mit Videos könnte man ähnlich verfahren und dann wäre die GUI-Library in der Anwendung nur noch ein dünner Wrapper für die GUI-API. Der große Nachteil dieser Variante ist das dadurch die GUI selber sehr groß und Feature-Reich wird und dann trotzdem nicht für absolut alle Fälle die passende Logik enthält.

Ich denke bei einer Anwendung die von sich aus zeichnen muss muss der Programmierer sich eh Gedanken über Effizienz und Energieverbrauch machen, da kommt der einfach nicht drumherum, egal was für Konzepte die GUI benutzt.


Grüße
Erik

[FlashBurn]

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?

[Svenska]

Hallo,

Gut, dann sage doch mal was nen modernen Desktop modern macht (du denkst dabei doch an bestimmte Features oder?).

Ja, ich denke an Compositing und Overlays. Das sind beides Dinge, die man mit einem VESA-artigen Treiber nur unter Schmerzen oder mit einem vollständig anderen Codepfad unterstützen kann.

Auf meine Frage ob das Linux mit seinen Framebuffer-Devices nicht auch macht, hast du leider nicht geantwortet.

Ja, weil Framebuffer Devices eine völlig andere Baustelle sind. Das hängt damit zusammen, dass auf nicht-x86 kein allgemeiner Standard für Textausgabe existiert und Linux daher eine solche API brauchte. Es gibt Framebuffer-Treiber mit Video- und 2D-Beschleunigung (letzteres z.B. der sonst kaputte viafb). Was du eigentlich meinst, ist etwas komplexeres (vgl. KMS), wobei KMS aus Kompatiblitätsgründen die fbdev-API bereitstellt. Das ist in meinen Augen alles historisches Kompatiblitätsgeraffel und mit einem modernem Desktop (Compositing) nicht vereinbar.

also mir persönlich gefällt das Konzept wo die Anwendung dazu aufgefordert wird Teile oder alles ihrer Fenster neu zu zeichnen absolut gar nicht.

Naja, wenn ich ein Fenster verschiebe, dann muss das Fenster, was da vorher (teilweise) hinter gelegen hat, davon erfahren und den Teil, der gerade freigelegt wurde, neu zeichnen.

Nö, in meiner (sicherlich naiven) Vorstellung ist auch das verdeckte (oder verkleinerte) Fenster in der GUI immer komplett vorhanden (ja ich weiß dass das Speicher kostet) und kann daher sofort ohne mitwirken der Applikation dargestellt werden.

Das ist richtig, bei Compositing ist das auch so. Allerdings kann man - wenn man die Anwendung zum Neuzeichnen auffordern kann - die eigentlichen Buffer auch wegwerfen, wenn der Speicher knapp ist. Die Buffer gehören nur in den Video-RAM, wenn die Grafikkarte das Compositing in Hardware machen kann, sonst sollte man das in den System-RAM tun.

Ich hab mir X11 vor etlichen Jahren nur mal kurz und nur recht oberflächlich angesehen. Vom Konzept her ist das wimre gar nicht mal so verkehrt wenn wohl auch die Umsetzung nicht mehr so ganz Zeitgemäß ist.

Ich kenne nur den Begriff "over-engineered". Einfach viel zu kompliziert und zu sehr auf die 80er-Jahre-Technologien zugeschnitten; inzwischen also total veraltet und größtenteils in den Bibliotheken neu und moderner implementiert. Deswegen ja auch der Ansatz, alles von der Anwendung machen zu lassen.

GTK und Qt machen eigentlich alles in SW und liefern an die GUI nur noch ein fertiges Bitmap, genau das finde ich persönlich eher ungeschickt und von der Performance her auch suboptimal.

Finde ich weniger, denn auch GTK und Qt nutzen Backend-Libraries (z.B. OpenGL oder Cairo), die durchaus hardwarebeschleunigt sein können. Ich bin der Meinung, eine GUI sollte sich weniger um die Innereien der Anwendungen kümmern müssen.

Ich behaupte mal mit einer passenden HW-Unterstützung und der Fähigkeit von der Grafik-Library diese Möglichkeiten auch durch das GUI-System hindurch effizient nutzen zu können sollte man einen schicken und modernen KDE-Desktop auch mit nem 100 MHz Pentium noch flüssig bedienbar machen können.

Das bezweifle ich. Klar kann man mit Spezialchips die CPU entlasten, aber zu der Zeit steckte da nicht mehr drin als ein Framebuffer mit Blitting und 4 MB VRAM. Compositing geht da einfach nicht sinnvoll.

Gut, auch wieder wahr, den Svenska zu ignorieren wäre einfach unhöflich.

lol

Stell Dir einfach mal ein animiertes GIF vor (um z.B. eine kleine Fortschrittsanimation anzuzeigen), da könnte doch die Anwendung sich immer per Event antriggern lassen

Das betrachte ich als vom Design her kaputt.

Ich glaube da hast Du mich missverstanden. Ich meine das die Anwendung sich z.B. von einem System-Timer regelmäßig antriggern lassen kann, ...

Achso, aber das hat ja mit der GUI nichts zu tun. Dass die Anwendung z.B. einen Timer-Tick jede Sekunde bekommt und ein Bildfenster (GIF-Element) neu zeichnen lässt, ist ja ne System-Sache; sie muss den Button ja auch neuzeichnen, wenn da grad einer mit der Maus draufklickt (oder drüberfährt).

Für richtige Videos sollte natürlich auch ne spezial-API vorhanden sein, obwohl ich schon der Meinung bin das das grundsätzlich auch ohne spezial-API möglich sein sollte solange die RAM-Performance und auch die PCI-Performance dabei gut mitspielen (was heute selbst für Full-HD als gegeben zu betrachten ist).

Wenn der Videodekoder intern mit einem YUV-Farbformat arbeitet (eigentlich immer), und die Grafikkarte direkt YUV malen kann, dann sollte man das nutzen können, besonders weil das bereits eine Komprimierung sein kann. (YUYV = 4 Byte für 2 Pixel, RGB = 3-4 Byte pro Pixel). Interessant wird es dann, wenn du Videos nebenbei laufen lässt und die GUI trotzdem nutzen möchtest.

Für ein einfaches Vollbildvideo kann man das natürlich auch in Software pinseln, aber das verschwendet Rechenzeit und damit Strom.

Scrollen würde ich persönlich ganz anders machen. Ich würde das komplette Bild in den Video-Speicher laden und der Grafikkarte nur noch sagen "da liegt ein Bild mit den Ausmaßen X:Y an Offset Z im Video-RAM, zeichne davon den Teilausschnitt von U:V mit H:W ins Frame an A:B". Wenn gescrollt wird muss dann immer nur U:V angepasst werden und fertig.

Stimme ich zu, allerdings ist das wiederum Aufgabe der Anwendung, das so zu implementieren. Je nach Fall ist das nämlich nicht möglich (wenn z.B. für jeden Scrollvorgang eine Datenbank befragt werden muss und die gesamte Datenbank zu groß ist). Die GUI selbst fordert von der Anwendung ja eigentlich nur den vorgerenderten Buffer und zeichnet ihn.

Das wäre aber nicht mehr effizient. Denn du würdest zeichnen ohne das es Sinn macht. Wieso z.B. den Speicherbus mit einer GIF-Animation belasten, obwohl das Fenster nicht zu sehen ist und das für vllt ein paar Minuten?

Weil es einerseits nicht weh tut, du aber andererseits jederzeit eine aktuelle Vorschau des Fensters anfordern kannst (vgl. die Win7-Taskleiste).

Wenn ich mir überlege, was das auch an CPU Leistung kosten würde, wenn alle meine Tabs ständig am zeichnen wären bzw was sich da einsparen lässt.

Andere Baustelle: Das Tab-Steuerelement weiß, welches Tab sichtbar ist und kann die Redraw-Ereignisse der untergeordneten Fenster weglassen bzw. das Neuzeichnen unterlassen. Ansonsten vermute ich, dass das neuzeichnen gemacht wird (eine Flash-Animation im Hintergrund kostet ordentlich CPU).

Anderes Bsp wäre wenn der Bildschirm aus wäre oder der Bildschirmschoner an wäre, da würden bei dir die Anwendungen alle schön weiterzeichnen. Auch ein blinkender Cursor muss nicht ständig aktualisiert werden, wenn das Fenster eh nicht zu sehen ist.

Der Cursor folgt dem Fokus, ist also immer im Vordergrund. Du kannst ja ein Ereignis definieren, was das Neuzeichnen unterbindet.

Das trifft auf den PC zu und Smartphones/Tablets sind auf dem besten Weg auch so viel RAM zu haben. Aber von der Rechenleistung her sollte es doch reichen, dass nicht alles in den RAM muss.

Dann musst du auf Compositing usw. komplett verzichten und dich mit den damaligen Technologien zufriedengeben. Das sehe ich bei der GUI etwas anders als sonst, weil da einfach die Möglichkeiten extrem gestiegen sind und ich das nicht als Bloat betrachte.

Ich habe heute erst wieder ein Spiel von 1999 in der Hand gehabt und die mind. Anforderungen lesen sich so, dass gerade mal 32MB RAM (unter Windows ab 95) benötigt werden und trotzdem war die Grafik für die damalige Zeit richtig gut.

Du hast das schon richtig formuliert: Für die damalige Zeit. Nicht für die heutige Zeit. Eine Oberfläche im Win95-Look lässt sich nicht mehr verkaufen und ein paar Dinge, die Compositing bietet, finde ich toll.

Ich würde das so implementieren das die GUI der Anwendung mit dem Return-Wert einer Zeichen-Aktion immer mitteilt ob das gezeichnete überhaupt komplett oder nur zum Teil und gar nicht sichtbar ist (bei gar nicht eventuell noch nach Grund unterteilt: Verdeckt, Minimiert, Monitor-Aus, usw).

Naja, ich würde der Anwendung einfach ein Ereignis schicken, was ihr mitteilt, dass sie vorerst nicht automatisch neuzeichnen muss. Bei normalen Anwendungsfenstern möchte man ja schon gerne ein aktuelles Vorschaubild haben, bei einem Browsertab im Hintergrund sieht man es ohnehin nicht (und wenn, kann man ja ein normales RedrawNow-Ereignis hinschicken).

Wieso muss sich die Anwendung um sowas kümmern? Das hat die GUI zu erledigen. Die Anwendung zeichnet neu wenn sie dazu aufgefordert wurde (was die Anwendung auch selbst tun kann).

Die Anwendung zeichnet neu, wenn sie dazu aufgefordert wurde oder wenn sie es für richtig hält. Ein Ereignis "du bist jetzt nicht sichtbar" und "du bist jetzt wieder sichtbar" reicht da aus, um ihr diese Entscheidung zu ermöglichen.

Die GUI hat sich darum nicht zu kümmern, weil das Anwendungsinterna sind. Entweder, die Anwendung kümmert sich um sich selbst oder sie muss von der GUI wie ein Baby behandelt werden.

Zumal willst du wirklich das eine Anwendung die Laufzeit deines Laptops beeinflusst, nur weil der Programmierer der Meinung war, das es so richtig wäre. Denn diese Methode heißt ja auch, dass die Anwendung das alle ignorieren kann (der Einfachheit wegen und weil es auf den meisten (allen?) anderen System auch so ist) und dann ist nix mehr mit Strom sparen.

Ja, genau das möchte ich. Der Programmierer kann nämlich auch Threads mit einer Endlosschleife im Hintergrund erzeugen und dann bringt das ebenfalls nichts. Wenn ich den Anwendungen nicht ein bisschen vertrauen kann, brauche ich keinen Computer mehr. Da stimme ich Erik vollkommen zu.

So wie ich mir das vorstelle, muss die Anwendung aber nichts darüber wissen ob das Fenster sichtbar ist und in welchem Bereich.

Nein, aber du musst diese Information der Anwendung ja nicht gezielt vorenthalten. Für normale Fenster ist das wirklich total unwichtig, für manche Steuerelemente (wie z.B. Tab-Container) ist das wieder relevant.

Hat das Fenster jetzt eine Animation, dann schickt jedes Mal wenn eine Änderung nötig ist, eine Nachricht an die GUI (meinet wegen nen Want-Redraw Event) und die GUI entscheidet ob das überhaupt nötig ist (zwecks Sichtbarkeit und sowas). Ist es nötig, wird nen Redraw-Event an das Fenster geschickt, ansonsten nicht.

Würde ich eher über einen Zustand im Fenster lösen, also das übergeordnete Fenster sagt dem Steuerelement "du bist gerade unsichtbar" und das Steuerelement schickt an das übergeordnete Fenster halt keine "Want Redraw Event"-Events mehr.

Ich finde übrigens folgende Herangehensweise sinnvoller:
- GUI schickt Fenster ein Redraw-Event, das Fenster zeichnet sich neu und antwortet mit einem "RedrawDone"-Event.
- Das Fenster findet, dass es sich neu zeichnen muss, tut das und sendet ein "RedrawDone"-Event.

Warum muss die GUI jedes Fenster antriggern/takten, damit der Bildschirm schicker aussieht? Man kann das zwar mit der Bildwiederholrate synchronisieren, aber wann triggert man eigentlich, wenn zwei Bildschirme mit unterschiedlichen Frequenzen angesteuert werden? (Da jedes Fenster einen eigenen Buffer hat, kann man es auch auf beiden Bildschirmen haben...) Daher sollte die GUI das Fenster nur bei bestimmten Ereignissen antriggern, nicht per Timer.

Denn ich als fauler Programmierer (und sind wir nicht alle faul ) würde mich nicht dafür interessieren (und ich möchte meinen dass das unter Windows und auch Java so ist) ob mein Fenster jetzt sichtbar ist und wo, sondern ich zeichne halt immer mit dem Bereich den ich bekomme neu (entsprechend meines Modells).

Du verlangst also vom Programmierer das er sich noch um Dinge kümmern muss, was eigentlich gar nicht sein müsste.

Vom Toolkit-Programmierer, ja. Nicht vom Anwendungsprogrammierer. Jedes Steuerelement muss selbst wissen, wie es auf bestimmte Ereignisse reagiert.

Wirkliche Effizienz wird auf der PC Platform nicht groß geschrieben.
Sowas siehst du auf Embedded Systemen und Konsolen. Dort wo die Ressourcen halt stark begrenzt sind.

Richtig. Dort hast du aber auch keine modernen Desktops.

Und Hand aufs Herz - um wieviel % CPU-Zeit geht es denn bei deiner kleinen GIF-Animation? Wenn du einen 486er mit ISA-Grafikkarte optimal ausreizen willst, dann hast du eben kein Compositing und keine Live-Vorschau der Fenster. Punkt. Das geht nicht. Willst du beides optimal unterstützen, hast du zwei komplett getrennte Codepfade, für ein Hobby-OS zuviel Aufwand. Dann bau lieber deinen VESA-Treiber so, dass er Buffer-Management, Compositing usw. im System-RAM durchführt und eine gerade so akzeptable Fähigkeitenliste simuliert.

FlashBurn: Das mit den Ports und dem IPC sind Implementierungsdetails, die ich ziemlich komplex finde. Eine single-threaded Anwendung blockt halt, während sie ein Ereignis verarbeitet, daran lässt sich nichts ändern. Multithreading vorzuschreiben halte ich für unsinnig, außerdem wird das Toolkit das ohnehin schon tun, wenn das für sinnvoll erachtet. Dein Vorschlag definiert genau, wie eine Anwendung intern zu funktionieren hat und das ist in meinen Augen ein Designfehler.

Gewöhn dich daran, dass andere Programmierer anders denken und erschwere ihren Stil nicht über das Notwendige hinaus. Du bist kein Jurist, der alles Unerwünschte verbieten muss.

Gruß,
Svenska

[FlashBurn]

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.

[erik.vikinger]

Hallo,

So wie ich mir das vorstelle, muss die Anwendung aber nichts darüber wissen ob das Fenster sichtbar ist und in welchem Bereich.

Das ist in meinen Augen eine zu starke Einschränkung. Ich denke bei den meisten Anwendungen kommen die meisten Redraw-Events von der Anwendung selber (weil sich die darzustellenden Daten geändert haben) und nicht von der GUI (Fenster verschoben o.ä.). In der Hinsicht ist auch diesen Bitten der Anwendung an die GUI einen Redraw anzufordern meiner Meinung nach eher Quatsch, die GUI macht doch dafür auch nur ein 'if (sichtbar)' und das kann auch in der GUI-Library innerhalb der Anwendung passieren, dazu ist keine IPC-Kommunikation erforderlich. Wenn z.B. in Qt jedes QWidges genau weiß ob es sichtbar ist oder nicht kann die Anwendung einfach ins Root-QWidget einen Redraw-Event einspeisen und jedes QWidget das sichtbar ist (wenn auch nur zum Teil) zeichnet neu und fordert dann alle seine unter QWidget's auf das auch zu tun, bei einem QWidget das nur teilweise sichtbar ist wird es eventuell Unter-QWidget's geben die gar nicht sichtbar sind so das diese nichts zeichnen und auch nicht ihre internen Unter-QWidget's zum neuzeichnen auffordern. Für eine Fenster-Vorschau (die ja nur relativ selten passiert) könnte die GUI dann ja einen Redraw-All-Event an die Anwendung schicken bei dem die Sichtbarkeit in allen QWidget's immer ignoriert wird. Das einzigste was man dazu bräuchte wäre eine effiziente Methode allen QWidget's präzise mitzuteilen ob sie sichtbar sind oder nicht und da würde sich IMHO der Return-Wert von der GUI nach einem Zeichenbefehl anbieten.

Hat das Fenster jetzt eine Animation, dann schickt jedes Mal wenn eine Änderung nötig ist, eine Nachricht an die GUI (meinet wegen nen Want-Redraw Event) und die GUI entscheidet ob das überhaupt nötig ist (zwecks Sichtbarkeit und sowas). Ist es nötig, wird nen Redraw-Event an das Fenster geschickt, ansonsten nicht.

Fürchterlich umständlich. Es geht um ein einfaches 'if (sichtbar)' und dafür 2 IPC-Vorgänge, Du findest doch sicher auch dass das ein bisschen daneben ist oder?

Das Modell kann ja gerne pro GIF Bild schon nen Buffer haben und die View würde diesen nur noch in den entsprechenden Bereich kopieren, aber ob das passiert entscheidet die GUI.

Also bei einer GIF-Animation würde ich das anders lösen. Die Anwendung gibt der GUI alle Bilder und sagt dann später nur noch welches Bild jeweils in dem vorgesehenen Rechteck dargestellt werden muss. Wenn das Fenster im Vordergrund ist sollten auch alle Bilder in den Video-RAM übertragen werden und die GUI muss nur noch im Frame-Descriptor in der Grafikkarte einen Pointer ändern, das ist dann effizient. Wenn das Fenster nicht im Vordergrund ist ändert die GUI nur in der internen Fenster-Repräsentation einen Pointer und wäre zumindest immer sofort in der Lage eine Vorschau zu liefern oder das Fenster in den Vordergrund zu bringen ohne das die Anwendung erst neu zeichnen muss. Der CPU-Aufwand pro Bildwechsel wäre dafür so minimal das es unerheblich ist ob das Fenster nun sichtbar ist oder nicht. Was mich an Deiner Beschreibung am meisten stört ist das Wort "kopieren". Kopieren ist für eine CPU der blödeste Job überhaupt, da ist die CPU voll beschäftigt und der Speicherbus voll ausgelastet und trotzdem hat keine einzige der CPU-Internen Recheneinheiten etwas sinnvolles zu tun. Gerade dieses Kopieren ist es was heutige GUIs so CPU-Intensiv macht, das möchte ich anders machen, in meiner GUI soll möglichst nie kopiert werden müssen (mit einem halbwegs modernen Grafikkontroller der jünger als 10 Jahre ist ist das auch nicht erforderlich, Grafikkarten können seit gut 10 Jahren Compositing in HW und ausreichend Video-RAM ist auch seit vielen Jahren vorhanden).

Denn ich als fauler Programmierer (und sind wir nicht alle faul )

Bitte schließe nicht von Dich auf andere. Ein Programmierer der sich nicht wenigstens ein bisschen für die Effizienz seiner Programme interessiert ist meiner persönlichen Meinung nach kein echter Programmierer (das heißt nicht das der Programmierer Nächte lang auch noch den letzten Takt an Effizienz raus quetschen muss aber wenigstens grundlegende Effizienz-Paradigmen sollte er berücksichtigen). Mit solchen Individuen (von denen es sicher einige gibt) möchte ich nicht auf eine Stufe gestellt werden.

Du verlangst also vom Programmierer das er sich noch um Dinge kümmern muss, was eigentlich gar nicht sein müsste.

Ich verlange von einem Programmierer das es sich zumindest etwas bemüht und das er sich mit dem was er da programmiert zumindest rudimentär auskennt. Sollte das jemand nicht schaffen so möchte ich seine Programme auch nicht auf meiner Plattform haben. Punkt! Die Programme derartig desinteressierter Programmierer dürften auch sonst nicht viel taugen.

Wirkliche Effizienz wird auf der PC Platform nicht groß geschrieben.

Das liegt aber auch oft nicht an den Programmierern selber sondern an deren Umfeld (Arbeitgeber usw.), das sollte bei einem Hobby-OS anders sein.

Meine Frage wäre aber, ist solch eine Aufteilung mit den bekannten Libs (Qt und sowas) überhaupt möglich?

Vielleicht nicht perfekt aber ganz bestimmt irgendwie, es würde mir sehr schwer fallen zu glauben das so generische Libraries wie Qt da unnötig einschränken.

Allerdings kann man - wenn man die Anwendung zum Neuzeichnen auffordern kann - die eigentlichen Buffer auch wegwerfen, wenn der Speicher knapp ist. Die Buffer gehören nur in den Video-RAM, wenn die Grafikkarte das Compositing in Hardware machen kann, sonst sollte man das in den System-RAM tun.

Ganz recht, in meiner Fantasie ist die GUI einer der wenigen Kandidaten (neben dem VFS mit seinem Cache) wo es sich lohnt das der Kernel bei Speicherknappheit mal anfragt ob man nicht ein wenig Speicher freigeben könnte. Wenn der Rechner total unter Druck ist dann wird der User es auch sicherlich verschmerzen können wenn ein Fenster mal einen Moment braucht bis es wieder was sinnvolles anzeigt, wenn der User es aus der Versenkung holt. Bei einem unterforderten System hat der User aber IMHO durchaus das Recht eine sofort reagierende GUI zu erwarten. Wenn ich eine fette Simulation laufen lasse die alle CPU-Leistung und allen Speicher benötigt dann dauert es eben etwas Zeit bis das Fenster der Office-Anwendung wieder benutzbar ist wenn ich es frisch in den Vordergrund hole (das wird mir schon die Festplatten-LED signalisieren), wenn sich mein Computer aber mit ein paar einfachen Webseiten langweilt dann ist es IMHO nicht zu viel verlangt das ein Fensterwechsel sofort erledigt ist. Leider kommt diesem Ideal weder Windows noch KDE auch nur nahe, hier sehe ich oft dass das OpenOffice-Fenster einen kurzen Moment benötigt bis wieder alle Buttons usw. klar sichtbar sind, klar ist dieser Moment recht kurz und ich kann damit gut leben aber in Anbetracht der Möglichkeiten der vorhandenen Hardware ist es einfach nur beschämend dass das nicht besser gehen mag.

Finde ich weniger, denn auch GTK und Qt nutzen Backend-Libraries (z.B. OpenGL oder Cairo), die durchaus hardwarebeschleunigt sein können.

Achso, dann is ja gut. Ich will auch nicht das sich die GUI-Library um die Internas der Anwendung kümmert sondern dass das was die GUI-Library-API anbietet möglichst effizient ausgeführt werden kann und da ist IMHO Hardwarebeschleunigung eine gute Möglichkeit aber die erfordert das schon möglichst früh in der Kette die Aktivität von der Anwendung in die GUI verlagert wird.

Ich behaupte mal mit einer passenden HW-Unterstützung und der Fähigkeit von der Grafik-Library diese Möglichkeiten auch durch das GUI-System hindurch effizient nutzen zu können sollte man einen schicken und modernen KDE-Desktop auch mit nem 100 MHz Pentium noch flüssig bedienbar machen können.

Das bezweifle ich. Klar kann man mit Spezialchips die CPU entlasten, aber zu der Zeit steckte da nicht mehr drin als ein Framebuffer mit Blitting und 4 MB VRAM. Compositing geht da einfach nicht sinnvoll.

Klar, die Grafikkarten zur Zeit eines Pentium 100 MHz waren nicht der Bringer aber eine Grafikkarte die jünger als 10 Jahre ist (also ausreichend RAM hat und Compositing anständig in HW unterstützt) sollte auch in Kombination mit einem alten Pentium 100 MHz einen gut bedienbaren und modern aussehenden KDE-Desktop ermöglichen.

Interessant wird es dann, wenn du Videos nebenbei laufen lässt und die GUI trotzdem nutzen möchtest.

Ja, ich erwarte absolut selbstverständlich die GUI auch dann noch benutzen zu können wenn in einem Fenster ein Video läuft. Selbst bei zwei Fenstern mit unabhängigen Videos erwarte ich das noch, solange das Decodieren der Videos die CPU nicht ans Limit bringt.

Stimme ich zu, allerdings ist das wiederum Aufgabe der Anwendung, das so zu implementieren.

Naja, wenn es sich wirklich nur um ein statisches Bild handelt (das eben einfach nur seeeehr groß ist) dann sollte sich die GUI-Library darum kümmern können das ordentlich gescrollt werden kann. Wenn die Daten aber wirklich erst von einem anderen System geliefert werden müssen ist das ganz klar etwas komplexer und erfordert in der eigentlichen Anwendung auch entsprechenden Code.

Ein Ereignis "du bist jetzt nicht sichtbar" und "du bist jetzt wieder sichtbar" reicht da aus, um ihr diese Entscheidung zu ermöglichen.

Eben, genau das finde ich auch.

Entweder, die Anwendung kümmert sich um sich selbst oder sie muss von der GUI wie ein Baby behandelt werden.

Mit der Aussage habe ich so meine Probleme. Denn was ist denn das was x86 und auch Windows oft vorgeworfen wird? Die Kompatibilität! Wieso also "alte" Sachen zulassen, wenn es vielleicht neuere (die dann vielleicht schwieriger umzusetzen sind) bessere Wege gibt?
Darum geht es doch eigentlich auch irgendwo bei einem Hobby-OS. Ansonsten würde erik keine eigene Architektur mit einem OS das bei einigen (vielen?) Sachen mit der "normalen" Welt bricht.

Es wird durch ein Interface doch eh vorgeschrieben wie man eine GUI programmiert und von daher sehe ich das als nicht so schlimm an. Zumal man sehr viel davon auch in den Toolkits verstecken kann und auch sollte.
Allerdings finde ich halt die "Einstellung" das wurde schon immer so gemacht und deswegen müssen wir es weiterhin so machen ein wenig (mindestens ) falsch.

Hier muss ich FlashBurn grundsätzlich zustimmen, zu arg an althergebrachtem festzuhalten ist auf jeden Fall der falsche Weg.
Mein IPC-System erzwingt u.a. das alle Anwendungen multithreading-tauglich sind, das trifft in jedem Fall die libc (welche ja auch von mir kommt) die dann threadsave sein muss, der Anwendungsprogrammierer muss sich damit aber nicht zwangsläufig auseinander setzen solange er nicht vor hat komplexere Anwendungen zu bauen die das IPC direkt nutzen. Wenn jemand auf eine Library aufsetzt die multithreading erwartet (z.B. Qt in vielen aber nicht allen Dingen) dann muss er sich auch damit auseinander setzen, wenn aber jemand nur die libc benutzt dann kann er darauf verzichten.


Grüße
Erik

[FlashBurn]

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

[Svenska]

Hallo,

Ist Compositing wirklich so schwer mit nem VESA-Treiber umzusetzen? Weil es wird in erster Linie ja "nur" der Speicherbus belastet und wenn man dann den fertigen Frame zusammenstellt, reicht es ja nur die nötigen Bereiche zu kopieren, oder übersehe ich da was?

Eigentlich nicht, es wird nur relativ aufwändig zu implementieren. Ich vermute, dass es gute Gründe gibt, bei VESA-only auf Compositing zu verzichten...

Ich dache bei Framebuffer-Devices immer daran, dass man nur den Framebuffer der Graka nutzen kann, wenn z.B. kein richtiger Treiber vorhanden ist (wie oft im Embedded/Smartphone/Tablet Bereich). Ich wusste nicht dass da sogar 2D-Beschleunigung (in welcher Form eigentlich?) mit dabei ist.

Zu einem Framebuffer-Treiber gehört auch mindestens ein Modesetting, oft auch dynamisch ("fbset" ist das Programm dafür). Der Export als /dev/fb* ist nur eine Möglichkeit, darauf zuzugreifen, aber ein fbdev-Treiber kann auch Overlays und Blitting anbieten, genaueres weiß ich aber auch nicht. Die werden über ioctl() auf das fb-Device genutzt.

Das würde ich auch wieder so implementieren, das dann wenn eine Vorschau nötig ist, diese erst angefordert wird.

Ja, z.B. über ein Redraw-Event. Das Fenster muss dafür ja nicht direkt sichtbar sein. Wie gesagt: Wenn das Fenster unsichtbar wird, schickst du ein Event, dass jetzt keine automatischen Redraws mehr nötig sind, und wenn es wieder sichtbar wird das Gegenereignis und ein Redraw-Event, dass die Anwendung auch den aktuellen Zustand malt.

Andere Baustelle: Das Tab-Steuerelement weiß, welches Tab sichtbar ist und kann die Redraw-Ereignisse der untergeordneten Fenster weglassen bzw. das Neuzeichnen unterlassen. Ansonsten vermute ich, dass das neuzeichnen gemacht wird (eine Flash-Animation im Hintergrund kostet ordentlich CPU).

Wenn die Anwendung das intern (Modell) in einem Buffer machen möchte, kann sie das ja auch tun. Es ist ja nicht so, dass es bei meinem Design unmöglich ist. Das wäre dann auch in Richtung Compositing in der Anwendung.

Ne, wieso? Das Tab-Steuerelement ist doch ein "Fenster", also gilt die Fenster-Abstraktion des GUI-Systems. Du hast nicht pro Anwendung einen Buffer, sondern pro Fenster, und das können bei normaler Nutzung auch mehrere Hundert sein (Steuerelemtente implementiert man sinnvollerweise als Fenster...) Deswegen ist das beim VESA-Treiber ja so schwierig umzusetzen, weil du alles im System-RAM vorhalten musst, einmal das fertige Bild und einmal jeden Buffer extra. Das macht es schwierig, die Unterschiede festzustellen und eine weitere Kopie des Bildschirminhalts zum Vergleichen ist unschön.

Der Snapshot würde dann immer aus einem Buffer mit dem Bildinhalt bestehen und bei nem Redraw-Event wird nur noch dieser Buffer genommen und an die GUI geschickt.

Naja, dazwischen würde ich warten, bis die Anwendung fertig gezeichnet hat.

Der Cursor folgt dem Fokus, ist also immer im Vordergrund.

Ich meinten nen Cursor in einer Konsole.

Ja eben. Da blinkt nichts, wenn das Fenster nicht aktiv ist.

Keine Frage, Compositing bietet schon ein paar tolle Sachen, auf die ich auch ungern verzichten möchte, aber ich gebe mich zumindest für mein OS (irgendwo muss ich ja Abstriche machen ) auch mit nem Win95 (eigentlich sogar Win3.11, weil ich mit Grafik noch nicht viel zu tun hatte) Look zu frieden.

Dann lass Compositing weg.

Nein, aber du musst diese Information der Anwendung ja nicht gezielt vorenthalten. Für normale Fenster ist das wirklich total unwichtig, für manche Steuerelemente (wie z.B. Tab-Container) ist das wieder relevant.

Wieso ist das für manche Steuerelemente wichtig (ich kenne mich da halt gar nicht aus)?

Weil manche Steuerelemente z.B. selbst für das Ein- und Ausblenden sorgen und das u.U. auch mit Animationen und anderen rechenintensiven Effekten aufpeppen können. Mehr Freiheit ist da schöner, als alles so festzunageln, wie man es gern hätte. Und in der Erstimplementation wirst du eh die Hälfte vergessen, weil du nicht dran gedacht hast.

Wer redet denn davon das die GUI die Fenster per Timer antriggert? Ich will ja das die GUI die Fenster zu bei bestimmten Ereignissen antriggert.

Das klang bei dir so, als ob die Anwendung ansagen muss, dass sie jetzt eine GIF mit 10 Bildern pro Sekunde darstellen möchte und dann von der GUI 10x/Sekunde angetriggert wird. Das kann die Anwendung aber auch selbst machen.

Richtig. Dort hast du aber auch keine modernen Desktops.

Was sind Smartphones und Tablets denn für dich? Für mich steckt da immernoch embedded Hardware drin (gut die so ca. auf nem Stand von x86 vor 10 Jahren ist, was die CPU betrifft).

Also Embedded und Embedded sind zwei verschiedene Dinge. Erst sagst du, dass Tablets/Smartphones von der Rechen- und 3D-/Grafikleistung mit PCs vergleichbar sind und dann sagst du, dass du sowas modernes nicht unterstützen willst. Was denn nun?

Moderne Desktops setzen moderne Hardware voraus. Ein S3C24xx mit Framebuffer ist dafür halt ungeeignet, ein OMAP4 mit 3D-Beschleuniger ist dafür sehr geeignet. Mein Navi hat keinen wirklichen Desktop (WinCE halt), ein Android-Tablet schon eher...

Wenn du einen 486er mit ISA-Grafikkarte optimal ausreizen willst, dann hast du eben kein Compositing und keine Live-Vorschau der Fenster. Punkt.

Stimme ich dir voll und ganz zu. Das müsste man dann halt abschalten können (das geht ja unter Windows mit den Features auch bis zu einem gewissen Punkt).

Du willst wirklich zwei getrennte GUI-Systeme bauen, einmal mit und einmal ohne Compositing. Naja, da will ich dich nicht von abhalten.

Eine single-threaded Anwendung blockt halt, während sie ein Ereignis verarbeitet, daran lässt sich nichts ändern. Multithreading vorzuschreiben halte ich für unsinnig, außerdem wird das Toolkit das ohnehin schon tun, wenn das für sinnvoll erachtet. Dein Vorschlag definiert genau, wie eine Anwendung intern zu funktionieren hat und das ist in meinen Augen ein Designfehler.

Mit der Aussage habe ich so meine Probleme. Denn was ist denn das was x86 und auch Windows oft vorgeworfen wird? Die Kompatibilität! Wieso also "alte" Sachen zulassen, wenn es vielleicht neuere (die dann vielleicht schwieriger umzusetzen sind) bessere Wege gibt?

Ich halte überflüssige Komplexität für schlecht. Das hat mit Kompatiblität nur wenig zu tun.

Allerdings finde ich halt die "Einstellung" das wurde schon immer so gemacht und deswegen müssen wir es weiterhin so machen ein wenig (mindestens ) falsch.

Ich finde Single-Threaded trotzdem sinnvoll. Erstmal ist es unglaublich einfach, für extrem viele Anwendungsfälle reicht es auch hin und man erspart sich viele Fehlerquellen. Der High-Performance-Webserver lighttpd basiert beispielsweise auch auf einem Thread und asynchronem I/O. Da man meistens sowieso dynamisch generierte Webseiten verwendet, ist das auch kein Bottleneck (die Rechenzeit, um statische Webseiten auszuliefern, ist gering).

Klar, die Grafikkarten zur Zeit eines Pentium 100 MHz waren nicht der Bringer aber eine Grafikkarte die jünger als 10 Jahre ist (also ausreichend RAM hat und Compositing anständig in HW unterstützt) sollte auch in Kombination mit einem alten Pentium 100 MHz einen gut bedienbaren und modern aussehenden KDE-Desktop ermöglichen.

Das ist ja auch der moderne Ansatz: Jede Form der GUI-Beschleunigung wird in der 3D-Hardware der Grafikkarte ausgeführt. Wenn du also in deinen P100 eine moderene 3D-Grafikkarte steckst (was schon nicht funktioniert...) dann hättest du einen modernen composited Desktop mit Effekten etc. in schnell. Theoretisch.

Naja, wenn es sich wirklich nur um ein statisches Bild handelt (das eben einfach nur seeeehr groß ist) dann sollte sich die GUI-Library darum kümmern können das ordentlich gescrollt werden kann. Wenn die Daten aber wirklich erst von einem anderen System geliefert werden müssen ist das ganz klar etwas komplexer und erfordert in der eigentlichen Anwendung auch entsprechenden Code.

Sehe ich anders. Die Anwendung, die prinzipiell mit großen Bildern konfrontiert sein könnte, weiß das in der Regel vorher und kann sich darum kümmern. Das heißt aber nicht, dass der Programmierer das zu Fuß machen muss, das sollte das Toolkit anbieten. Wenn die GUI mit Bildern der zwei- bis fünffachen Bildschirmauflösung klarkommt und schnell arbeitet, dann reicht das. Es gibt ja auch gute 3D-Grafikkarten mit nur 32 MB Speicher oder so, da passt das Bild eh nicht rein.

In der Hinsicht ist auch diesen Bitten der Anwendung an die GUI einen Redraw anzufordern meiner Meinung nach eher Quatsch, die GUI macht doch dafür auch nur ein 'if (sichtbar)' und das kann auch in der GUI-Library innerhalb der Anwendung passieren, dazu ist keine IPC-Kommunikation erforderlich.

Das würde so wie ich mir es vorstelle nicht klappen. Bei mir müsste sich die Anwendung selbst eine Nachricht schicken. Denn diese Nachricht wird ja in einem anderen Thread ausgeführt und der wird für die Nachricht erstellt und ruft dann den Code auf.

Implementierungsdetail. Wenn das so nicht geht, hast du entweder ein kaputtes Design oder du musst dir eben was anderes einfallen lassen.

Allerdings werden halt neue Sprachen deswegen "erfunden", weil die meisten Programmierer faul sind und so wenig wie möglich schreiben wollen.

Perl: Write Once, Read Never. Danke, ich verzichte. Die Programmiergeschwindigkeit zu erhöhen macht die Anwendungen nicht unbedingt besser...

Ansonsten kann ich sagen, dass ne moderne GUI (Ubuntu 11.10) auch auf nem Framebuffer-Device (ohne Hardwarebeschleunigung) funktionieren, habe ich selbst im Einsatz. Das einzige was nicht funktioniert sind Videos (weil halt zu viel kopiert werden muss).

Dafür hast du aber kein XRENDER, kein EXA, kein XVideo und insbesondere kein Compositing.

Gruß,
Svenska

[FlashBurn]

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?

[erik.vikinger]

Hallo,

Bei mir müsste sich die Anwendung selbst eine Nachricht schicken. Denn diese Nachricht wird ja in einem anderen Thread ausgeführt und der wird für die Nachricht erstellt und ruft dann den Code auf.

Dann rufst Du Dein "Zeichne-Neu"-System eben per Create-Thread() auf (über ne winzige Stub-Funktion die die Aufrufparameter passend setzt, so wie beim IPC-Receive-Stub ja auch) und schon ist die Sache erledigt, sorry aber Du machst Probleme wo keine sind.

Naja, wenn du es so siehst, dann dürften wir nicht an nem MikroKernel schreiben. Weil seien wir ehrlich nen Monolith ist was das betrifft wesentlich effizienter.

Bitte schließe nicht von Dir auf andere! Wenn Du denkst das Dein Micro-Kernel-Design nicht an einen Monolithen heran reicht, okay, aber ich denke über mein Micro-Kernel-Design anders. Ich behaupte Eleganz (im Design und im Code) mit hoher Performance und Effizienz kombinieren zu können. Ob das auch tatsächlich in der Realität klappt muss ich ganz klar erst noch beweisen, das ist mir bewusst, aber ich gehe heute zumindest davon aus das ich das auch hinkriege, sonst würde ich das ganze Projekt erst gar nicht versuchen.

Die Anwendung gibt der GUI alle Bilder und sagt dann später nur noch welches Bild jeweils in dem vorgesehenen Rechteck dargestellt werden muss.

Aber würde das nicht heißen das du extra für solche Sachen ein Feature in der GUI haben wirst?

Ja, aber ein Feature das ich für extrem nützlich halte und das man an sehr vielen Stellen anwenden kann. Denke da nur mal an gedrückte Buttons oder Maus-Over-Effekte, auch da wäre es sinnvoll alle Varianten schon vorher vorzubereiten und der GUI als fertige Bilder zu übermitteln um dann nur noch auszuwählen welches Bild man in dem entsprechenden Widget haben will. Die einzigste Komplexität ist im Speichermanagement für den Video-RAM (die GUI muss sich überlegen welche Bilder da alles rein sollen, bevorzugt von Fenstern die gerade sichtbar sind) und ein kleiner Plausibilitätstest beim Wechseln des Bildes (das neue muss natürlich auch die richtige Auflösung usw. haben) und beim Killen des Fensters müssen auch alle zugehörigen Bilder aus der GUI entfernt werden.

Bei ner modernen Graka wo man nen Treiber für hat, kann man doch bestimmt der Graka sagen das sie nen bestimmten Speicherbereich aus dem System-RAM holen soll

Ja, und man kann dabei auch gleich noch eine Farbraum-Konvertierung durchführen lassen, so das die Grafikkarte intern alles mit 32Bit-RGBA benutzt und die Anwendung aber trotzdem ein 256 Farben-Bild mit Palette der GUI übergeben kann oder auch YUV. Das alles geht dann ohne zusätzliche CPU-Last und genau das ist das Ziel.

(aber auch da ist der Speicherbus belastet und auch das ist irgendwo kopieren).

Ja schon, aber das CPU-Netzwerk wird trotzdem etwas weniger belastet (außerdem könnte die Grafikkarte die Transferrate künstlich niedrig halten wenn es nicht eilt, oder mehrere unabhängige DMA-Queues für unterschiedliche Prioritäten haben) und Du hast eine CPU mehr für wirklich nützliche Dinge zur Verfügung.

Das dürfte in dem Fall am PCI-Bus scheitern. Ansonsten wäre es wahrscheinlich schon möglich.

Klar kann man eine moderne Grafikkarte nicht in einen PC aus der Zeit des 100 MHz Pentium reinstecken (und selbst wenn würde das nicht zum gewünschten Ergebnis führen), es geht mir einfach nur um die Aussage das für eine moderne GUI (mit allem (un)nötigen Schnick und Schnack) in einem modernen System (inklusive moderner Grafikkarte) nicht mehr als die CPU-Leistung eines 100 MHz Pentium erforderlich sein sollte. Nicht mehr und nicht weniger. Dass das unter aktuellen OSen nicht klappt liegt IMHO an einem schlechten Software-Design und nicht an der Hardware.

Ansonsten kann ich sagen, dass ne moderne GUI (Ubuntu 11.10) auch auf nem Framebuffer-Device (ohne Hardwarebeschleunigung) funktionieren, habe ich selbst im Einsatz. Das einzige was nicht funktioniert sind Videos (weil halt zu viel kopiert werden muss).

Und wie viele Prozente Deiner CPU-Leistung wird für die GUI geopfert? Offensichtlich so viel das es nicht mal für Video reicht. Klar kann auch ein schlechtes Konzept erstmal brauchbar funktionieren aber es bleibt ein schlechtes Konzept.

Naja, wenn es sich wirklich nur um ein statisches Bild handelt (das eben einfach nur seeeehr groß ist) dann sollte sich die GUI-Library darum kümmern können das ordentlich gescrollt werden kann. Wenn die Daten aber wirklich erst von einem anderen System geliefert werden müssen ist das ganz klar etwas komplexer und erfordert in der eigentlichen Anwendung auch entsprechenden Code.

Sehe ich anders. Die Anwendung, die prinzipiell mit großen Bildern konfrontiert sein könnte, weiß das in der Regel vorher und kann sich darum kümmern. Das heißt aber nicht, dass der Programmierer das zu Fuß machen muss, das sollte das Toolkit anbieten. Wenn die GUI mit Bildern der zwei- bis fünffachen Bildschirmauflösung klarkommt und schnell arbeitet, dann reicht das. Es gibt ja auch gute 3D-Grafikkarten mit nur 32 MB Speicher oder so, da passt das Bild eh nicht rein.

Klar funktioniert das nur bis zu einer gewissen Größe nur allein über den Video-RAM, deswegen habe ich ja auch vorgeschlagen das man für wirklich große Bilder (also deutlich mehr als das 4-fache der Bildschirmauflösung) auf jeden Fall kacheln sollte und in den Video-RAM nur die Kacheln lädt die auch momentan gesehen werden können (und eventuell noch die umliegenden Kacheln falls das Fenster wirklich im Vordergrund ist (und auch tatsächlich vom User bedient werden kann) und genügend Video-RAM verfügbar ist). Dass das von der GUI-Library, die direkt in die Anwendung gelinkt wird, passend unterstützt werden muss ist klar. Bei Java-Swing-GUI gibt es da eine JScrollPane die aber leider auch nur den Redraw-Event passen umsetzt und weiter nach unten reicht, schöner wäre es wenn die JScrollPane das gesamte enthaltene Element zeichnen lassen würde und beim Bewegen der Scrollbalken einfach immer nur den passenden Ausschnitt nach oben reichen würde (oder am besten HW-Beschleunigung nutzen tät) anstatt bei jeder Scrollbewegung immer ein beschnittenes Redraw-Event nach unten zu reichen. Die benutze Methode muss natürlich davon abhängig sein wie groß das enthaltene Element ist (aber das weiß die ScrollPane ja auch da ansonsten die Scrollbalken nicht passend skaliert werden könnten). Wenn ich mir im Browser ab und an mal ein paar große Bilder ansehe (und diese auf 1:1-Darstellung umschalte) dann hab ich immer sehr hässliche Effekte wenn ich scrolle, und das obwohl ich den proprietären NVidea-Treiber installiert hab (also eigentlich HW-Unterstützung vorhanden sein sollte, der Video-RAM ist auf jeden Fall ausreichend). Es ist einfach frustrierend zu wissen das der Computer das problemlos könnte aber die Software das einfach nicht nutzt sondern lieber umständlich händisch kopiert.

Ich gehe fest davon aus, dass ich die GUI (und wahrscheinlich auch meinen Kernel) mehrmals neu schreiben werde.

Hm, so sehr überzeugt bist Du von Deinen Fähigkeiten? Da würde ich mir dann aber lieber ein anderes Hobby suchen. SCNR


Grüße
Erik

[FlashBurn]

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.

[Svenska]

Hallo,

Das heißt also dass Compositing schon in der Anwendung stattfindet? Ich dachte das die GUI, die Buffer der Fenster hat und nicht die Anwendung selbst.

Die GUI hat ja auch alle Buffer, aber eine Anwendung hat eben nicht nur 2-3 Fenster (mit jeweils eigenem Buffer), sondern die meisten Steuerelemente haben ebenfalls einen. Die GUI verwaltet nur die Buffer und bastelt sie zu einem Desktop zusammen.

Naja, dazwischen würde ich warten, bis die Anwendung fertig gezeichnet hat.

Das wäre ja der Vorteil mit diesem Design, man würde Multithreading richtig nutzen und hätte immer sofort ein Bild ohne das die GUI großartig warten muss.

Zwischen "ich beginne jetzt mit dem Zeichnen" und "ich habe fertig gezeichnet" vergeht immer Zeit, ob du nun Multithreading nutzt oder nicht...

Ja eben. Da blinkt nichts, wenn das Fenster nicht aktiv ist.

Naja, aber so wie du und erik das so erklären, würde die Anwendung trotzdem immer den blinkenden Cursor zeichnen (es sei denn die Anwendung hätte das implementiert mit dem sichtbar und unsichtbar).

Du vermischst Baustellen. Wenn die Anwendung den Fokus verliert, dann gibt es keinen Cursor mehr. Der ist dann weder sichtbar, noch unsichtbar, noch blinkt er.

Das mit den Effekten ist natürlich war (kannst du mal ein konkretes Bsp. bringen?), aber das müsste doch trotzdem bei mir gehen. Dann kommt halt erst ne Nachricht dass das Fenster jetzt wieder sichtbar ist (am besten an das Modell und nicht die View, obwohl ich mir da gerade nicht sicher bin) und dann ne Nachricht zum Redraw (die ja eh kommen muss).

Bei Steuerelementen, die für einen Redraw sehr lange brauchen können, denke ich an z.B. Oszilloskopdarstellungen, wo jeder Messwert mit den vergangenen Messwerten verrechnet werden muss und das sinnvollerweise ständig passiert, ob das Fenster (Steuerelement) nun sichtbar ist oder nicht. Das Ereignis "du bist grad nicht sichtbar" kann ja dazu führen, dass die Vorberechnungen trotzdem weitergeführt werden.

Ansonsten hab ich keine konkreten Beispiele.

Erst sagst du, dass Tablets/Smartphones von der Rechen- und 3D-/Grafikleistung mit PCs vergleichbar sind und dann sagst du, dass du sowas modernes nicht unterstützen willst. Was denn nun?

Mir ging es darum, das dort ja auch Compositing zu funktionieren scheint und die Leistung halt noch nicht auf aktuellem x86 Niveau ist.

Für gutes Compositing brauchst du keinen Quadcore-Prozessor mit 3 GHz und einer OpenGL 4.2 Grafikkarte. Da reichen auch 600 MHz und ein Grafikchipsatz, der das unterstützt. Gibts den nicht, wird kein Compositing implementiert.

Denn ich habe mir das so vorgestellt, dass der Treiber die Buffer fürs Compositing bereit stellt und die Anwendung da dann reinzeichnet und der VESA-Treiber würde halt anstatt vieler einzelner Buffers immer einen Teil des Framebuffers (obwohl das auch schwierig ist, weil man da ja anders zeichnen müsste, zwecks andere Zeilenlänge und sowas (Farbraum!)).

Das geht nicht. Du müsstest im VESA-Treiber jeden Buffer extra haben und eine Kopie des Framebuffers, in den du die einzelnen Buffer zeichnest. Für genügend RAM ist das möglich, aber eben recht viel Overhead und damit nicht optimal. Was du denkst, ist eher so ein "eine Anwendung, ein Buffer" und dann zeichnest du die direkt in den Framebuffer. Das geht auch, beschränkt aber die Möglichkeiten des Compositings.

Wie wird das mit dem Farbraum eigentlich gemacht, muss das die Anwendung wissen oder wandelt der Treiber oder die GUI dann die 32bit/24bit in den jeweiligen Farbraum um?

Implementierungssache. Sinnvoll ist eine Liste mit Formaten (fourcc), die die GUI/Hardware darstellen kann und die Anwendung muss dann in eins dieser Formate konvertieren.

Dafür hast du aber kein XRENDER, kein EXA, kein XVideo und insbesondere kein Compositing.

Wie bekomme ich denn raus, ob Compositing benutzt wird oder nicht?

Stellst du im Window Manager ein - und siehst eigentlich an den Effekten, ob es aktiv ist oder nicht.

Ja, aber ein Feature das ich für extrem nützlich halte und das man an sehr vielen Stellen anwenden kann. Denke da nur mal an gedrückte Buttons oder Maus-Over-Effekte, auch da wäre es sinnvoll alle Varianten schon vorher vorzubereiten und der GUI als fertige Bilder zu übermitteln um dann nur noch auszuwählen welches Bild man in dem entsprechenden Widget haben will.

In deiner Denkweise mag das stimmen, aber deine Denkweise ist nicht alles. Es gibt Qt, GTK und noch ein paar Dutzend weiterer Widget-Bibliotheken, die aus jeweils ein paar hundert Bitmaps bestehen (wenn überhaupt). Präventiv alle möglichen Bilder in den VRAM zu tun ist böse. Außerdem verlierst du die Möglichkeit der gemeinsamen Nutzung.

Klar funktioniert das nur bis zu einer gewissen Größe nur allein über den Video-RAM, deswegen habe ich ja auch vorgeschlagen das man für wirklich große Bilder (also deutlich mehr als das 4-fache der Bildschirmauflösung) auf jeden Fall kacheln sollte und in den Video-RAM nur die Kacheln lädt die auch momentan gesehen werden können (und eventuell noch die umliegenden Kacheln falls das Fenster wirklich im Vordergrund ist (und auch tatsächlich vom User bedient werden kann) und genügend Video-RAM verfügbar ist).

Und dem stimme ich vollkommen zu. Allerdings sehe ich die Pflicht da eher in der Anwendung bzw. im Toolkit, nicht um GUI-System. Bei aktivem Compositing handelt es sich größtenteils um Buffer-Management, wenn du da bei vollem Video-RAM einen 8192*32768 großen Buffer beantragst, dann geht das halt nicht. Damit muss die Anwendung selbst klarkommen.

Gruß,
Svenska

[FlashBurn]

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.

[Svenska]

Die GUI hat ja auch alle Buffer, aber eine Anwendung hat eben nicht nur 2-3 Fenster (mit jeweils eigenem Buffer), sondern die meisten Steuerelemente haben ebenfalls einen. Die GUI verwaltet nur die Buffer und bastelt sie zu einem Desktop zusammen.

Jetzt bin ich verwirrt. Wo ist welcher Speicher gemappt?

Das ist Sache des Grafiktreibers, bei VESA ziemlich sicher der System-RAM. Moderne Grafikkarten können gebrauchbare Speicherverwaltung und haben teilweise sogar MMUs...

Ich dachte das geht so ähnlich wie, man bekommt nen Redraw von der GUI und bekommt auch gleich nen Buffer mit wo man reinschreiben kann (oder man muss sich diesen Buffer erst von der GUI holen) und wenn man dann fertig ist und das der GUI sagt, dann ist der Buffer auch weg.

Wozu? Dann hast du doch verdammt viel Overhead beim Alloziieren/Dealloziieren von diesen Buffern. Total umständlich und langsam.

Jedes Fenster (also auch die meisten Steuerelemente) haben einen Buffer, wo sie reinmalen. Der wird alloziiert, wenn das Fenster erzeugt wird und freigegeben, wenn das Fenster zerstört wird. Und in diesem Buffer darf rumgemalt werden, soviel und sooft man möchte. Aufgabe des Grafiktreibers ist es dann, diese Buffer entsprechend ihrer Reihenfolge so zusammenzubauen, dass am Ende ein Framebuffer entsteht.

Die GUI sagt dann der Graka das sie diesen Buffer in ihren eigenen Speicher laden kann (und das wird für jedes Fenster gemacht).

Nicht unbedingt. Die Buffer kann (und sollte) man sinnvollerweise direkt im VRAM halten, weil die Hardware das Compositing von dort erledigen kann. Effektiv läuft das darauf hinaus, dass man jedes Fenster (Steuerelement) als Textur betrachtet und dann eine Kamerafahrt über die Flächen macht, nur halt in 2D.

Auch dachte ich das die Anwendung zwar für jedes Steuerelement nen eignen Buffer hat, aber die GUI bekommt immer nen anderen Buffer "zurück" und die Anwendung kopiert in diesen Buffer aus ihren eigenen Buffern rein.

"Kopieren". Das ist böse. Die Anwendung fordert einen Buffer pro Steuerelement an und die GUI zeichnet diese Buffer dann. Ein Steuerelement kann auch mehrere Buffer halten und dann der GUI sagen, welcher der gerade aktive Buffer ist (Double-Buffering vermeidet Tearing).

Der Sinn des ganzen liegt darin, dass die Daten in dem Buffer nicht unbedingt von der CPU kommen müssen, sondern z.B. auch per DMA von einer Spezialhardware (3D-Beschleunigerchip, SLI, ...) kommen können. Bei Embedded-Chips hast du meistens einen relativ simplen Framebuffer (mit wenigen 2D-Beschleunigungsfunktionen), der Modesetting macht und Overlays bietet und dann ein 3D-Teil von PowerVR, was da direkt drin rummalen kann (und nicht dokumentiert ist).

Zwischen "ich beginne jetzt mit dem Zeichnen" und "ich habe fertig gezeichnet" vergeht immer Zeit, ob du nun Multithreading nutzt oder nicht...

Das ist mir klar, aber so wie ich es vorgeschlagen habe, wäre immer ein Bild vorhanden (muss ja nicht komplett aktuell sein) und man müsste nur den Buffer kopieren/senden ohne das die CPU irgendwas großartig rechnen/zeichnen müsste.

Ich möchte gerne das aktuelle Bild sehen und kein veraltetes. Beispiel: Filme und Spiele.

Wenn die Anwendung den Fokus verliert, dann gibt es keinen Cursor mehr. Der ist dann weder sichtbar, noch unsichtbar, noch blinkt er.

Da wäre meine Frage ist, was für eine Animation schwebt dir vor, wo eine Anwendung wissen will ob man sie sieht oder nicht? Denn es macht mehr Sinn das eine Anwendung weiß ob sie gerade den Focus hat und wenn sie wieder bekommt eine Animation zeichnet.

Es gibt nur einen systemweiten Fokus (solange du nur eine Tastatur/Maus unterstützt). Die Sichtbarkeit betrifft aber auch Anwendungen im Hintergrund, z.B. bei 3D-Effekten fürs (automatisierte) Ein-/Ausblenden. Das muss nicht sein, wenn es nicht nötig ist. Praktische Anwendungsfälle hab ich keine, lassen sich aber konstruieren.

Genau dafür ist doch das MVC Konzept gut. Das Modell rechnet fleißig weiter, aber es wird nix gezeichnet. Denn man braucht ja nur die Werte und die kann man auch im Modell speichern.

Ja, aber das sollte das Steuerelement bei mir selbst bestimmen dürfen und nicht von der GUI vorgeschrieben kriegen.

Implementierungssache. Sinnvoll ist eine Liste mit Formaten (fourcc), die die GUI/Hardware darstellen kann und die Anwendung muss dann in eins dieser Formate konvertieren.

Hmm, das gefällt mir irgendwie nicht. Wieso muss die Anwendung das wissen? Wurde das so auch unter Windows, Linux und anderen GUIs gemacht?

Für XVideo gibt es eine Liste mit fourcc-Formaten, die die Hardware nativ unterstützt. Farbraumkonvertierungen machen Treiber nicht, das ist unter Linux verpönt (deswegen gibt es auch die libv4l2, die die ganzen kranken Webcam-Formate konvertieren kann; früher hat das der Treiber gemacht, was je nach Format viel Zeit im Kernel bedeutet und die Echtzeitfähigkeit komplett zerstört). Insbesondere YUV gibt es ja in vielen Geschmacksrichtungen. X11 selbst unterstützt ebenfalls nur eine gewisse Menge an Pixmap-Formaten und Visuals, die Liste gibt es vom Programm "xdpyinfo".

Mir würde es eher gefallen, das ne Anwendung immer in 24bit (wann braucht man eigentlich mal 32bit sprich den Alphachannel?) zeichnet und die GUI wandelt das dann um oder man müsste das im Toolkit verstecken. Auf jeden Fall so, dass der Programmierer sich darüber keine Gedanken machen muss.

Dagegen. Wenn du dich auf 24 Bit Farbtiefe festlegst, nagelst du Anwendungen fest. Der Alpha-Channel wird für Halbtransparenz gebraucht, außerdem kann man das als Chroma-Keying oder für Metadaten benutzen. Inzwischen gibt es auch 30-Bit-Displays, die angesteuert werden könnten und wenn du nur 8 Bit Farbtiefe unterstützt, dann musst du auch keine 24-Bit-Buffer bereithalten, die nur Speicher kosten.

Insbesondere Videosoftware wird mindestens ein bisschen YUV machen wollen, wenn das möglich ist und auch Bildverarbeitungssoftware kann davon profitieren. Daher würde ich den anderen Weg gehen: Die GUI bietet eine Liste mit möglichen Formaten an und die Anwendung kann sich davon eins pro Buffer aussuchen - andere Formate werden nicht unterstützt und müssen von der Anwendung selbst (bzw. dem Toolkit) konvertiert werden.

Gruß,
Svenska