Re: Migrations-Tool

Manfred Haertel, DB3HM schrieb:
> AW schrieb:
> 
>> Ich lese hier gelegentlich mit und bin immer wieder sehr erstaunt über 
>> die
>> Vorbehalte gegenüber wayland.
> 
> Ich habe keine "Vorbehalte" gegenüber Wayland. Im Gegenteil, es gibt 
> einige gute Design-Ansätze in Wayland (schlechte auch, wie in jeder 
> Software).
> 
> Tatsache ist aber, dass es (bei mir) immer noch in bestimmten Kontexten 
> Artefakte oder krude (intermittierende) Performance-Probleme gibt und 
> neue Features wie der RDP-Server schlicht nicht funktionieren. Da 
> erwarte ich von einer Software, die seit 18 Jahren entwickelt wird, 
> einfach ein wenig mehr.

Die Ursache meiner intermittierenden Performance-Probleme mit Wayland 
habe ich nach einer längeren Debug-Session gefunden.

Ich hatte immer mal wieder "Ruckeler", also Animationen waren nicht 
"flüssig", sondern "ruckelig" - und zwar je nach "Tagesform" 
unterschiedlich stark ruckelig - oder es war alles in Ordnung - 
letzteres in mindestens 50% aller Fälle - aber ohne erkennbar 
unterschiedliche Randbedingungen. Udd vor allen Dingen ohne dass die CPU 
am Anschlag wäre.

Wie von Anfang an vermutet liegt es am Compositing-Timer innerhalb von 
kwin_wayland, der das Intervall vorgibt, bei dem der nächste 
Compositing-Vorgang vorgenommen wird, also geschaut wird, ob sich was in 
den Buffern der Clients verändert hat und dann wird das ausgegeben.

Die Stelle, wo dieser Timer berechnet wird, habe ich schließlich auch 
gefunden und die Berechnung des Warte-Wertes für den Timers ist 
ultra-kompliziert unter Zuhilfenahme weiterer Timestamps und etlicher 
Fallunterscheidungen. Ich blicke bei der Berechnung jedenfalls nicht durch.

Was ich aber durch Debug-Ausgaben herausgefunden habe: Es gibt einen 
Timestamp, der angeblich angibt, zu welchem Zeitpunkt das LETZTE 
Compositing stattgefunden hat. Und der liegt manchmal in der Zukunft - 
unterschiedlich weit in der Zukunft, was die unterschiedliche 
Ruckeligkeit erklärt. Liegt er z.B. eine halbe Sekunde in der Zukunft 
wird eben mindestens diese halbe Sekunde gewartet plus dem berechneten 
Offset.

Wenn ich die ultrakomplizierte Berechnung durch einen konstanten Wert 
ersetze sind meine Performance-Probleme jedenfalls weg und zwar ohne 
erkennbare Seiteneffekte. Das ist sicher nicht die richtige Lösung, aber 
sie funktioniert für mich.

Blöderweise scheint es noch mal deutlich aufwändiger zu sein zu 
verstehen, warum der Timestamp in der Zukunft liegt. Und so lange ich 
das nicht weiß, kann ich auch keinen Bug-Report aufmachen, der würde 
sofort als nicht nachvollziehbar geschlossen.

Randbemerkung: Diese Performance-Probleme konnte ich besonders gut 
nachvollziehen, wenn kwin_wayland "nested" unter einem anderen 
Wayland-Compositor läuft - ich kann nicht ausschließen, dass sie mit dem 
DRM-Backend nicht auftreten, sehe aber erst mal keine Abhängigkeit des 
Problems vom Backend. Außerdem ist der "nested"-Betrieb ein 
unterstütztes Feature von Wayland, es muss also auch hier gehen. Und es 
liegt auch sicher an kwin_wayland, da es mit weston nicht passiert.

-- 
Manfred Härtel, DB3HM    mailto:[email protected]
                          http://rz-home.de/mhaertel