Die Gnome- User kommen beim Wechsel auf KDE vom Regen unter der Umgehung der Traufe direkt in die Schei§e. Wenn schon Flucht, dann wohl besser zu XFCE....
nach 4 Jahren KDE4-Entwicklung ist das Grundsystem langsam halbwegs stabil
Wenn KDE4.4 einem KDE4.2 und KDE4.8 einem KDE4.3 entsprochen hätten, wären die ganzen Diskussionen über Stabilität und Co so in der Form nicht aufgetreten. Diesen Schuh müssen sich die Entwickler imho allein anziehen - sie haben die Plattform entworfen. Wenn ich als Entwiclker eine Plattform entwerfe die auf nicht unterstützen Grafikkarten-Funktionen setzt, muss ich mich nicht wundern das es zu Problemen kommt.
Wenn ich mich richtig erinner hat es in der der "vor" KDE4 Phase geheissen - "Deutlich performanter Dank QT4, deutlich schnellere Entwicklung, Deutlich besser dank Plasmon" - als reiner Anwender habe "ich" davon keine "Vorteile" gespürt: KDE4 wirkt selbst in v4.8 noch Träger als KDE3.5, Plasmon bietet mir persönlich keine Vorteile - dafür hat man mit Desktop-Bugs leben dürfen.
Inzwischen ist KDE aber einigermassen ausgereift.... - und kommt imho als Gesamtpaket wieder an die guten alten KDE3.5 Zeiten heran
Von mgraesslin am Do, 6. September 2012 um 10:24 #
Wenn ich als Entwiclker eine Plattform entwerfe die auf nicht unterstützen Grafikkarten-Funktionen setzt, muss ich mich nicht wundern das es zu Problemen kommt.
Huh? Bitte was? KDE hat nie irgendwelche Grafikkarten-Funktionen vorausgesetzt und wird dies in der 4.x Zeit nicht tun. KDE funktioniert immer noch sehr gut ohne OpenGL Compositing (das ist wohl was du meinst - nichts anderes bräuchte überhaupt Grafikkarten Unterstützung).
Mir ist daher nicht klar was du meinst. Vielleicht meinst du ja das Problem was wir in 4.5 hatten mit einigen Treibern. Nun habe ich darüber ausführlich berichtet. Aber nochmal für dich: wir haben die Treiber gefragt, ob sie das kann, sie haben "ja" geantwortet, haben aber eigentlich gelogen. Tja ist natürlich unser Fehler wenn wir das zu dem Zeitpunkt seit zwei Jahren so machen und es nie Probleme gab sondern erst als die Treiber meinten das jetzt auch zu können.
Hallo, ich meinte die diverrsen Crash-und Performance-Probleme in den frühen KDE-Versionen (v4.1 - v4.5).
>> Aber nochmal für dich: wir haben die Treiber gefragt, ob sie das kann, sie haben "ja" geantwortet, haben aber eigentlich gelogen.
Keine Frage - das ist ungünstig und auch erstmal nicht die Schuld der KDE-Entwickler. Aber... Als Entwickler stelle ich doch ab irgent einem Zeitpunkt fest - "das läuft nicht so wie es soll". Dann suche ich nach den Ursachen, und stelle in diesem Fall fest, dass die Grafikkarte Funktion xyz nicht unterstuetzt. Wenn ich dann weiter forsche stelle ich fest andere Grafikkarten haben auch ihre Probleme.
Dann muss ich "imho" als Entwickler einer "stabilen Plattform" hingehen und mir eine alternative Lösung überlegen - und kann mich nicht hinstellen und sagen - "KDE ist performant - beschwer Dich beim Hersteller". Und wenn das Problem sich nur durch "unschoenes gefrickel" lösen lässt - muss dies "imho" in Kauf genommen, oder über gesonderte Tools Lösungen gefunden werden. Spätestens nach KDE4.0/4.1 dürfte auch allen Entwicklern klar gewesen sein, das die Distros alle nach und nach auf KDE4 schwenken - und die bis dahin bekannten Probleme massiv breitgetretzen würden. Wie gesagt, das Problem betraf viele unterschiedliche Grafikkarten, von diversen Herstellern.
Das Problem war insbesondere für Laien wie mich unverstaendlich - da
1. KDE3.x / Gnome2 sich bereits via GPU beschleunigen liessen und nette Effekte wie "Transparenz und Co" deutlich performanter als CPU-Beschleunigt zuliessen. Insbesondere das "verschieben" eines Fensters ueber dem anderen verlief so ohne spürbare CPU-Last. Unter Gnome2 wurde das vergroessern von Fenstern via "Rahmen" gelöst - so dass auch hier "0" CPU-Last benötigt wurde.
2. nVidia stellt bereits seit ca. 2001/2002 stabile OpenGL-Treiber für GNU/Linux zur Verfügung, mit denen sich aufwendige Games wie Quake3/Doom3 spielen lassen. Intressanter weise war hier die Performance sogar spürbar "höher" als unter Windows.
3. Mit KDE4.4 oder KDE4.5 wurde der "Icon-Cache" von einem externen Entwickler verbessert - als er beim debuggen von Performance-Problemen feststellte das diese hunderte male Reloaded wurden. Als Laie ist es für mich hier unverstaendlich das a) jemand externes so etwas aufdeckt, wenn schon seit Jahren diverse Leute sich bezüglich der Performance beschweren, und b) das die Lösung ein verbesserter Cache darstellt - imho stellt sich die frage - wieso müssen diese immer wieder neugeladen werden - und waere es nicht besser sich zu ueberlegen ob/wie man das vermeiden kann.
=====================================
Aber bei all dem gemecker der letzten Jahre - Der Test mit KDE4.8 zeigt das die grossen Stabilitäts-Probleme insbesondere mit Plasma der Vergangenheit angehöhren. Auch sind alle benötigten Grundfunktionen eines Desktops sind für den Anwender sehr komfortabel abgebildet... Dafür von mir ein Danke an all die Entwickler !! (insbesondere die die hier meine Beiträge lesen durften :-))
Wenn ich mir etwas für die Zukunft wünschen "dürfte" wäre es die Möglichkeit Fenster rein via "Rahmen" zu verschieben/vergroessern. Insbesondere unter VMware spürt man aufgrund der fehlenden GPU-Unterstuetzung hier noch Performance-Einbrüche beim verschieben/vergroessern von Fenstern (20-30% CPU-Last bei 2core 3,5GHz). Die bestehenden Rahmenslösungen helfen da wenn überhaupt nur marginal.
Von mgraesslin am Do, 6. September 2012 um 14:07 #
Als Entwickler stelle ich doch ab irgent einem Zeitpunkt fest - "das läuft nicht so wie es soll". Dann suche ich nach den Ursachen, und stelle in diesem Fall fest, dass die Grafikkarte Funktion xyz nicht unterstuetzt. Wenn ich dann weiter forsche stelle ich fest andere Grafikkarten haben auch ihre Probleme.
Danke für diesen grandiosen Hinweis, da wäre ich ja gar nicht drauf gekommen, dass wir das hätten untersuchen müssen. Upps hab nur zig Stunden jeden Tag darauf investierte.
Nun denn das erste Problem war, dass es erstmalig wenn ich mich richtig erinnere im RC auftrat - das ist etwas spät. Dann kam hinzu, dass zum Beispiel ich nur eine NVIDIA Karte hatte und die Probleme bei mir nicht nachvolziehen konnte (andere KWin Entwickler übrigens auch nicht), dann kam hinzu, dass es auf nur ein paar Kombinationen auftrat.
Was hätten wir denn machen sollen deiner Meinung nach? Komplett 4.5 absagen weil wir festgestellt haben, dass es mit manchen Treibern bei mancher Hardware bei manchen Distributionen (zu dem Zeitpunkt war ausschließlich Arch betroffen) zu Performance Problemen kommen kann?
Also bitte, wenn man so neun mal klug kommt, was hätten wir besser machen können? Ich bin davon überzeugt, dass ich mit dem mir damals zur Verfügung stehenden wissen, alles richtig gemacht habe.
KDE3.x / Gnome2 sich bereits via GPU beschleunigen liessen und nette Effekte wie "Transparenz und Co" deutlich performanter als CPU-Beschleunigt zuliessen.
Jo, mittels XRender, dann bitte mal in die Treiber schauen und feststellen, dass das dann doch größtenteils auf der CPU ist.
Mit KDE4.4 oder KDE4.5 wurde der "Icon-Cache" von einem externen Entwickler verbessert - als er beim debuggen von Performance-Problemen feststellte das diese hunderte male Reloaded wurden.
Hmm nein, der wurde von Michael Pyne verbessert, noch mehr Kernentwickler von KDE als mpyne geht kaum.
Von mgraesslin am Do, 6. September 2012 um 15:41 #
mittlerweile bin zumindest ich gut versorgt (dreht sich um zu der Kiste mit Grafikkarten) und damals hätte es mir auch nichts gebracht, da mein System ein Notebook war.
>> Was hätten wir denn machen sollen deiner Meinung nach? Komplett 4.5 absagen weil wir festgestellt haben, ich hatte mich jetzt eher auf "frühen" KDE-Probleme bezogen (KDE4.1-4.5) nicht direkt auf KDE4.5. Aber auch hier gilt meiner Meinung - wenn sich "gravierende" Probleme für den Enduser auftun sollten die vorher gefixed werden... - kjedenfalls wenn ich davon ausgehen kann das 20% oder mehr der Enduser davon betroffen sind.
>> Jo, mittels XRender, dann bitte mal in die Treiber schauen und feststellen, dass das dann doch größtenteils auf der CPU ist.
Ich bin kein Entwickler - es mag sein das das bei der CPU liegt - der Effekt als Anwender war seinerzeit 0% CPU Verbrauch. Der Effekt in KDE4.8 unter SuSE12.2/Kubuntu ohne unterstützte GPU sind 20% CPU-Verbrauch. Wenn sich das Problem durch "einfache" Rahmendarstellung beheben liesse wuerde KDE hier "gefühlt flüssig" laufen. Im übrigen gabs die Funktion bis einschl. KDE4.2 oder später auch noch. Sie war allerdings verbuggt (Fensterdekos wurden sporadisch falsch dargestellt).
>> Hmm nein, der wurde von Michael Pyne verbessert, noch mehr Kernentwickler von KDE als mpyne geht kaum. Hmm nagut, dann hab ich das wohl falsch verstanden... - was aber nicht beantwortet ob ein "besserer Chache" wirklich eine Lösung ist...
Von mgraesslin am Do, 6. September 2012 um 15:46 #
ich hatte mich jetzt eher auf "frühen" KDE-Probleme bezogen (KDE4.1-4.5) nicht direkt auf KDE4.5.
Dann ist aber alles was du zu dem Punkt geschrieben hast Quatsch, denn wir hatten nur in 4.5 Probleme mit GPUs.
Aber auch hier gilt meiner Meinung - wenn sich "gravierende" Probleme für den Enduser auftun sollten die vorher gefixed werden... - kjedenfalls wenn ich davon ausgehen kann das 20% oder mehr der Enduser davon betroffen sind.
Richtig und die Probleme konnten nur in den Treibern behoben werden oder von Distributionen durch richtige Zusammenstellung der Komponenten. Und wenn überhaupt waren vielleicht 5 % der Nutzer betroffen.
Im übrigen gabs die Funktion bis einschl. KDE4.2 oder später auch noch. Sie war allerdings verbuggt (Fensterdekos wurden sporadisch falsch dargestellt).
Nein sie wurde von mir entfernt, da sinnbefreit. Hatte auch nichts mit verbuggt zu tun, war einfach nur komplett inkompatibel zu Compositing.
>> Dann ist aber alles was du zu dem Punkt geschrieben hast Quatsch, denn wir hatten nur in 4.5 Probleme mit GPUs.
Aha, und die diversen Crashes in Plasma, der Taskleiste dem Desktop in KDE4.1-4.3 habe ich mir nur ausgedacht? Und die Begründungen das KDE stabil sei, und das das problem an meinem Grafiktreiber läge hab ich mir auch gerade nur ausgedacht?
>> Nein sie wurde von mir entfernt, da sinnbefreit.
100% CPU Auslastung beim Resizen von Fenstern soll sinnig sein, wenn keine GPU-Beschleunigung zur Verfügung steht? Oder habe ich eventuell eine verfügbare Option übersehen?
"Systemeinstellungen > Desktop-Effekte > Alle Effekte > Fenstergröße ändern " vermindert das unmittelbare Ruckeln bei der Größenänderung, dennoch ist die CPU-Last bei 100%.
>> Hatte auch nichts mit verbuggt zu tun, war einfach nur komplett inkompatibel zu Compositing. Dennoch gabs mit der eingeschalteten Option in diversen Distros Bugs (Mandriva, SuSE, Kubuntu)
Von mgraesslin am Do, 6. September 2012 um 17:50 #
>> Dann ist aber alles was du zu dem Punkt geschrieben hast Quatsch, denn wir hatten nur in 4.5 Probleme mit GPUs.
Aha, und die diversen Crashes in Plasma, der Taskleiste dem Desktop in KDE4.1-4.3 habe ich mir nur ausgedacht?
Das lag ganz bestimmt nicht an der Grafikkarte, denn Plasma nutzt kein OpenGL.
Und die Begründungen das KDE stabil sei, und das das problem an meinem Grafiktreiber läge hab ich mir auch gerade nur ausgedacht?
Ich verstehe gerade nicht was du meinst?
100% CPU Auslastung beim Resizen von Fenstern soll sinnig sein, wenn keine GPU-Beschleunigung zur Verfügung steht? Oder habe ich eventuell eine verfügbare Option übersehen?
100 % CPU Auslastung beim Resizen von Fenstern ist niemals sinnig. Melde Bugs an die Anwendungen, welche solche Probleme verursachen. Das bedeutet nämlich meistens, dass sie das Sync Protokoll nicht beherrschen.
Werden fenster nur mit "Rahmen" vergroessert (zb via WindowManager) steigt die CPU-Last nicht sehr stark - sobald ein Fenster als Vollbild vergroessert wird, steigt die CPU-Last auf einer CPU gegen 100%. Gleiches gilt fürs verschieben von Fenstern.
Als Nachteil bei der Rahmendarstellung ist mir aufgefallen, das während der Groessenänderung alle anderen Fenster nicht aktualisiert werden (zb ksysguard am unteren Bereich des Fensters). Sobald ich die Maustaste beim "Vergroessern" loslasse, werden alle Fenster wieder aktualisiert.
Damit nehm ich dann wohl mal die "KDE"-Performance-Diskussion zurück... - wobei imho durch eine reine Rahmendarstellung zumindestens das Problem oberflächlich gelöst würde ...
Hmm nein, der wurde von Michael Pyne verbessert, noch mehr Kernentwickler von KDE als mpyne geht kaum.
Jo, das hat mich jetzt auch sehr verwundert
Jo, mittels XRender, dann bitte mal in die Treiber schauen und feststellen, dass das dann doch größtenteils auf der CPU ist.
Was ja auch weiterhin verfügbar ist. Hatte bei meinem alten Laptop Schwierigkeiten bei OpenGL Verwendung (zwei Grafikkarten mit sehr unterschiedlicher Leistung) und daher XRender für Effekte aktiviert. Lief einwandfrei!
Ich habe eine Nvidia Karte und wenn ich KDE Desktop unter Ubuntu installiere, dann ist der erst mal schwarz mit Mauszeiger. Woran liegt es, keine Ahnung, ich muss Compositing abschalten durch Editieren der Konfigurationsdateien von Kwin. Nun könnte natürlich KDE das auch erst mal erkennen, ob meine Grafikkarte das unterstützt aber nö.
Von ------------------------------ am Do, 6. September 2012 um 13:32 #
Was glaubst Du, wer das auf Deinem Blog bitte lesen soll?
-> bugreport? idealerweise auf bugs.kde.org un nicht hier und mit präziseren informationen zur eingesetzten HW / Treiber und dem verwendeten Compositor?
Bei einer nvidia GPU jenseits von GeForce2 tippe ich aber mal auf nouveau (experimentelle OpenGL Unterstützung seitens des Treibers, nicht für Endnutzer) oder krude GLES bauten (das, resp. EGL, kann der nvidia Treiber mangels KMS-Unterstützung eigentlich nicht) Der nvidia Treiber wird einfach so durchgelassen, weil er in der Hinsicht wirklich der unproblematischste ist.
Pixelvaliditätstests gab es mal ganz früher, aber das hat mehr Ärger als Nutzen gebracht.
Im Blog steht nur wie man das Problem für sich löst, wenn es auftritt, übrigens eine Regression. Das haben nämlich mehrere Leute gehabt. Dazu gab es schon Bug Reports. Die Sache ist gemein für Leute, die kein Peil haben, was man tun kann. Die Googlen das Netz, finden einen Hinweis.
Gibt es denn da einen einfachen Befehl für die Shell, mit dem man alle möglicherweise relevanten Daten über die aktuelle Konfiguaration extrahieren kann?
Von ------------------------------ am Do, 6. September 2012 um 21:38 #
> übrigens eine Regression um das beurteilen zu können, müßte man das Problem erst mal exakt eingrenzen (wenn es bspw. Auftritt weil ein Treiber plötzlich irgendwas behauptet, was er nicht wirklich unterstützt, ist das kaum eine regression, weil sich am KWin code dann im Zweifel nichts geändert hätte)
> Dazu gab es schon Bug Reports Wo? Ich behaupte, daß er mir auf bugs.kde.org aufgefallen wäre (->link?) Das einzige, was mir dazu einfiele wäre nvidias "black window" bug, aber das war vor Jahren (und hat afair auch nie den ganzen Desktop betroffen)
> Gibt es denn da einen einfachen Befehl für die Shell
Wie gesagt: qdbus org.kde.kwin /KWin supportInformation
wenn aber kein compositor aktiv ist, sind da natürlich auch keine informationen über den compositor (oder openGL) enthalten -> glxinfo
Wenn's tatsächlich der "nvidia black window" bug sein sollte, wird es vermutlich ausreichen XLIB_SKIP_ARGB_VISUALS=1 zu exportieren und/oder den Blur effekt zu deaktivieren (Speichermangel auf der GPU) Der lag aber definitiv bei nvidia, xrender compositing sollte weiterhin funktionieren.
Außerdem läßt sich der Compositor mit Shift+Alt+F12 jederzeit de/aktivieren (es ist also nicht notwendig auf VT1 zu arbeiten o.ä.)
...wird jetzt vermutlich auch bald upgedated werden.
Das ist wirklich sehr Interessant.
So sieht es aus!
Die Gnome- User kommen beim Wechsel auf KDE vom Regen unter der Umgehung der Traufe direkt in die Schei§e. Wenn schon Flucht, dann wohl besser zu XFCE....
blablabla
Also KDE könnte ja wieder richtig was werden, wenn die endlich mal vernünftiges Testing machen würden. In der Zwischenzeit nutze ich lieber LXDE.
Übrigens, wie macht man eigentlich Dolphin zum Default-Filemanager unter Unity? Ich finde Unity ganz prima aber der Filemanager ist sowas von grottig.
nach 4 Jahren KDE4-Entwicklung ist das Grundsystem langsam halbwegs stabil
Wenn KDE4.4 einem KDE4.2 und KDE4.8 einem KDE4.3 entsprochen hätten, wären die ganzen Diskussionen über Stabilität und Co so in der Form nicht aufgetreten.
Diesen Schuh müssen sich die Entwickler imho allein anziehen - sie haben die Plattform entworfen. Wenn ich als Entwiclker eine Plattform entwerfe die auf nicht unterstützen Grafikkarten-Funktionen setzt, muss ich mich nicht wundern das es zu Problemen kommt.
Wenn ich mich richtig erinner hat es in der der "vor" KDE4 Phase geheissen - "Deutlich performanter Dank QT4, deutlich schnellere Entwicklung, Deutlich besser dank Plasmon" - als reiner Anwender habe "ich" davon keine "Vorteile" gespürt: KDE4 wirkt selbst in v4.8 noch Träger als KDE3.5, Plasmon bietet mir persönlich keine Vorteile - dafür hat man mit Desktop-Bugs leben dürfen.
Inzwischen ist KDE aber einigermassen ausgereift.... - und kommt imho als Gesamtpaket wieder an die guten alten KDE3.5 Zeiten heran
Huh? Bitte was? KDE hat nie irgendwelche Grafikkarten-Funktionen vorausgesetzt und wird dies in der 4.x Zeit nicht tun. KDE funktioniert immer noch sehr gut ohne OpenGL Compositing (das ist wohl was du meinst - nichts anderes bräuchte überhaupt Grafikkarten Unterstützung).
Mir ist daher nicht klar was du meinst. Vielleicht meinst du ja das Problem was wir in 4.5 hatten mit einigen Treibern. Nun habe ich darüber ausführlich berichtet. Aber nochmal für dich: wir haben die Treiber gefragt, ob sie das kann, sie haben "ja" geantwortet, haben aber eigentlich gelogen. Tja ist natürlich unser Fehler wenn wir das zu dem Zeitpunkt seit zwei Jahren so machen und es nie Probleme gab sondern erst als die Treiber meinten das jetzt auch zu können.
Hallo,
ich meinte die diverrsen Crash-und Performance-Probleme in den frühen KDE-Versionen (v4.1 - v4.5).
>> Aber nochmal für dich: wir haben die Treiber gefragt, ob sie das kann, sie haben "ja" geantwortet, haben aber eigentlich gelogen.
Keine Frage - das ist ungünstig und auch erstmal nicht die Schuld der KDE-Entwickler.
Aber...
Als Entwickler stelle ich doch ab irgent einem Zeitpunkt fest - "das läuft nicht so wie es soll". Dann suche ich nach den Ursachen, und stelle in diesem Fall fest, dass die Grafikkarte Funktion xyz nicht unterstuetzt. Wenn ich dann weiter forsche stelle ich fest andere Grafikkarten haben auch ihre Probleme.
Dann muss ich "imho" als Entwickler einer "stabilen Plattform" hingehen und mir eine alternative Lösung überlegen - und kann mich nicht hinstellen und sagen - "KDE ist performant - beschwer Dich beim Hersteller". Und wenn das Problem sich nur durch "unschoenes gefrickel" lösen lässt - muss dies "imho" in Kauf genommen, oder über gesonderte Tools Lösungen gefunden werden.
Spätestens nach KDE4.0/4.1 dürfte auch allen Entwicklern klar gewesen sein, das die Distros alle nach und nach auf KDE4 schwenken - und die bis dahin bekannten Probleme massiv breitgetretzen würden.
Wie gesagt, das Problem betraf viele unterschiedliche Grafikkarten, von diversen Herstellern.
Das Problem war insbesondere für Laien wie mich unverstaendlich - da
1. KDE3.x / Gnome2 sich bereits via GPU beschleunigen liessen und nette Effekte wie "Transparenz und Co" deutlich performanter als CPU-Beschleunigt zuliessen. Insbesondere das "verschieben" eines Fensters ueber dem anderen verlief so ohne spürbare CPU-Last. Unter Gnome2 wurde das vergroessern von Fenstern via "Rahmen" gelöst - so dass auch hier "0" CPU-Last benötigt wurde.
2. nVidia stellt bereits seit ca. 2001/2002 stabile OpenGL-Treiber für GNU/Linux zur Verfügung, mit denen sich aufwendige Games wie Quake3/Doom3 spielen lassen. Intressanter weise war hier die Performance sogar spürbar "höher" als unter Windows.
3. Mit KDE4.4 oder KDE4.5 wurde der "Icon-Cache" von einem externen Entwickler verbessert - als er beim debuggen von Performance-Problemen feststellte das diese hunderte male Reloaded wurden.
Als Laie ist es für mich hier unverstaendlich das
a) jemand externes so etwas aufdeckt, wenn schon seit Jahren diverse Leute sich bezüglich der Performance beschweren, und
b) das die Lösung ein verbesserter Cache darstellt - imho stellt sich die frage - wieso müssen diese immer wieder neugeladen werden - und waere es nicht besser sich zu ueberlegen ob/wie man das vermeiden kann.
=====================================
Aber bei all dem gemecker der letzten Jahre - Der Test mit KDE4.8 zeigt das die grossen Stabilitäts-Probleme insbesondere mit Plasma der Vergangenheit angehöhren. Auch sind alle benötigten Grundfunktionen eines Desktops sind für den Anwender sehr komfortabel abgebildet...
Dafür von mir ein Danke an all die Entwickler !!
(insbesondere die die hier meine Beiträge lesen durften :-))
Wenn ich mir etwas für die Zukunft wünschen "dürfte" wäre es die Möglichkeit Fenster rein via "Rahmen" zu verschieben/vergroessern. Insbesondere unter VMware spürt man aufgrund der fehlenden GPU-Unterstuetzung hier noch Performance-Einbrüche beim verschieben/vergroessern von Fenstern (20-30% CPU-Last bei 2core 3,5GHz). Die bestehenden Rahmenslösungen helfen da wenn überhaupt nur marginal.
Viele Grüße
Andre
Nun denn das erste Problem war, dass es erstmalig wenn ich mich richtig erinnere im RC auftrat - das ist etwas spät. Dann kam hinzu, dass zum Beispiel ich nur eine NVIDIA Karte hatte und die Probleme bei mir nicht nachvolziehen konnte (andere KWin Entwickler übrigens auch nicht), dann kam hinzu, dass es auf nur ein paar Kombinationen auftrat.
Was hätten wir denn machen sollen deiner Meinung nach? Komplett 4.5 absagen weil wir festgestellt haben, dass es mit manchen Treibern bei mancher Hardware bei manchen Distributionen (zu dem Zeitpunkt war ausschließlich Arch betroffen) zu Performance Problemen kommen kann?
Also bitte, wenn man so neun mal klug kommt, was hätten wir besser machen können? Ich bin davon überzeugt, dass ich mit dem mir damals zur Verfügung stehenden wissen, alles richtig gemacht habe.
Jo, mittels XRender, dann bitte mal in die Treiber schauen und feststellen, dass das dann doch größtenteils auf der CPU ist.Hmm nein, der wurde von Michael Pyne verbessert, noch mehr Kernentwickler von KDE als mpyne geht kaum.Nur eine Karte hatte. Hey, vielleicht solltet ihr das mal kommunizieren. Was ihr gerne hättet/testen würdet mit Postanschrift.
mittlerweile bin zumindest ich gut versorgt (dreht sich um zu der Kiste mit Grafikkarten) und damals hätte es mir auch nichts gebracht, da mein System ein Notebook war.
Auch das kann man ja lösen durch Hardwarespenden. Nvidiakarten kann man auch für 5 Eur bei ebay kaufen.
>> Was hätten wir denn machen sollen deiner Meinung nach? Komplett 4.5 absagen weil wir festgestellt haben,
ich hatte mich jetzt eher auf "frühen" KDE-Probleme bezogen (KDE4.1-4.5) nicht direkt auf KDE4.5. Aber auch hier gilt meiner Meinung - wenn sich "gravierende" Probleme für den Enduser auftun sollten die vorher gefixed werden... - kjedenfalls wenn ich davon ausgehen kann das 20% oder mehr der Enduser davon betroffen sind.
>> Jo, mittels XRender, dann bitte mal in die Treiber schauen und feststellen, dass das dann doch größtenteils auf der CPU ist.
Ich bin kein Entwickler - es mag sein das das bei der CPU liegt - der Effekt als Anwender war seinerzeit 0% CPU Verbrauch. Der Effekt in KDE4.8 unter SuSE12.2/Kubuntu ohne unterstützte GPU sind 20% CPU-Verbrauch. Wenn sich das Problem durch "einfache" Rahmendarstellung beheben liesse wuerde KDE hier "gefühlt flüssig" laufen. Im übrigen gabs die Funktion bis einschl. KDE4.2 oder später auch noch. Sie war allerdings verbuggt (Fensterdekos wurden sporadisch falsch dargestellt).
>> Hmm nein, der wurde von Michael Pyne verbessert, noch mehr Kernentwickler von KDE als mpyne geht kaum.
Hmm nagut, dann hab ich das wohl falsch verstanden... - was aber nicht beantwortet ob ein "besserer Chache" wirklich eine Lösung ist...
>> Dann ist aber alles was du zu dem Punkt geschrieben hast Quatsch, denn wir hatten nur in 4.5 Probleme mit
GPUs.
Aha, und die diversen Crashes in Plasma, der Taskleiste dem Desktop in KDE4.1-4.3 habe ich mir nur ausgedacht?
Und die Begründungen das KDE stabil sei, und das das problem an meinem Grafiktreiber läge hab ich mir auch gerade nur ausgedacht?
>> Nein sie wurde von mir entfernt, da sinnbefreit.
100% CPU Auslastung beim Resizen von Fenstern soll sinnig sein, wenn keine GPU-Beschleunigung zur Verfügung steht? Oder habe ich eventuell eine verfügbare Option übersehen?
"Systemeinstellungen > Desktop-Effekte > Alle Effekte > Fenstergröße ändern " vermindert das unmittelbare Ruckeln bei der Größenänderung, dennoch ist die CPU-Last bei 100%.
>> Hatte auch nichts mit verbuggt zu tun, war einfach nur komplett inkompatibel zu Compositing.
Dennoch gabs mit der eingeschalteten Option in diversen Distros Bugs (Mandriva, SuSE, Kubuntu)
Melde Bugs an die Anwendungen, welche solche Probleme verursachen.
Na super... - xorg
Werden fenster nur mit "Rahmen" vergroessert (zb via WindowManager) steigt die CPU-Last nicht sehr stark - sobald ein Fenster als Vollbild vergroessert wird, steigt die CPU-Last auf einer CPU gegen 100%. Gleiches gilt fürs verschieben von Fenstern.
Als Nachteil bei der Rahmendarstellung ist mir aufgefallen, das während der Groessenänderung alle anderen Fenster nicht aktualisiert werden (zb ksysguard am unteren Bereich des Fensters). Sobald ich die Maustaste beim "Vergroessern" loslasse, werden alle Fenster wieder aktualisiert.
Damit nehm ich dann wohl mal die "KDE"-Performance-Diskussion zurück... - wobei imho durch eine reine Rahmendarstellung zumindestens das Problem oberflächlich gelöst würde ...
>> Dann kam hinzu, dass zum Beispiel ich nur eine NVIDIA Karte hatte und die Probleme bei mir nicht nachvolziehen konnte
.. daran sollte die KDE-Entwicklung nun wirklich nicht hängen..
Ein einziger Aufruf bei Pro-Linux sollte genuegen um solche Problem zu lösen.
Jo, das hat mich jetzt auch sehr verwundert
Was ja auch weiterhin verfügbar ist. Hatte bei meinem alten Laptop Schwierigkeiten bei OpenGL Verwendung (zwei Grafikkarten mit sehr unterschiedlicher Leistung) und daher XRender für Effekte aktiviert. Lief einwandfrei!
Ich habe eine Nvidia Karte und wenn ich KDE Desktop unter Ubuntu installiere, dann ist der erst mal schwarz mit Mauszeiger. Woran liegt es, keine Ahnung, ich muss Compositing abschalten durch Editieren der Konfigurationsdateien von Kwin. Nun könnte natürlich KDE das auch erst mal erkennen, ob meine Grafikkarte das unterstützt aber nö.
http://arebentisch.wordpress.com/2012/08/15/kde-black-screen-upgrade-issue/
Was glaubst Du, wer das auf Deinem Blog bitte lesen soll?
-> bugreport?
idealerweise auf bugs.kde.org un nicht hier und mit präziseren informationen zur eingesetzten HW / Treiber und dem verwendeten Compositor?
qdbus org.kde.kwin /KWin supportInformation
*mit* aktiviertem compositing
Hilfe im KDE forum?
Bei einer nvidia GPU jenseits von GeForce2 tippe ich aber mal auf nouveau (experimentelle OpenGL Unterstützung seitens des Treibers, nicht für Endnutzer) oder krude GLES bauten (das, resp. EGL, kann der nvidia Treiber mangels KMS-Unterstützung eigentlich nicht)
Der nvidia Treiber wird einfach so durchgelassen, weil er in der Hinsicht wirklich der unproblematischste ist.
Pixelvaliditätstests gab es mal ganz früher, aber das hat mehr Ärger als Nutzen gebracht.
Im Blog steht nur wie man das Problem für sich löst, wenn es auftritt, übrigens eine Regression. Das haben nämlich mehrere Leute gehabt. Dazu gab es schon Bug Reports. Die Sache ist gemein für Leute, die kein Peil haben, was man tun kann. Die Googlen das Netz, finden einen Hinweis.
Gibt es denn da einen einfachen Befehl für die Shell, mit dem man alle möglicherweise relevanten Daten über die aktuelle Konfiguaration extrahieren kann?
> übrigens eine Regression
um das beurteilen zu können, müßte man das Problem erst mal exakt eingrenzen (wenn es bspw. Auftritt weil ein Treiber plötzlich irgendwas behauptet, was er nicht wirklich unterstützt, ist das kaum eine regression, weil sich am KWin code dann im Zweifel nichts geändert hätte)
> Dazu gab es schon Bug Reports
Wo? Ich behaupte, daß er mir auf bugs.kde.org aufgefallen wäre (->link?)
Das einzige, was mir dazu einfiele wäre nvidias "black window" bug, aber das war vor Jahren (und hat afair auch nie den ganzen Desktop betroffen)
> Gibt es denn da einen einfachen Befehl für die Shell
Wie gesagt:
qdbus org.kde.kwin /KWin supportInformation
wenn aber kein compositor aktiv ist, sind da natürlich auch keine informationen über den compositor (oder openGL) enthalten ->
glxinfo
Wenn's tatsächlich der "nvidia black window" bug sein sollte, wird es vermutlich ausreichen XLIB_SKIP_ARGB_VISUALS=1 zu exportieren und/oder den Blur effekt zu deaktivieren (Speichermangel auf der GPU)
Der lag aber definitiv bei nvidia, xrender compositing sollte weiterhin funktionieren.
Außerdem läßt sich der Compositor mit Shift+Alt+F12 jederzeit de/aktivieren (es ist also nicht notwendig auf VT1 zu arbeiten o.ä.)