Libreoffice 6.0 und 6.1 Draw unter KDE/Plasma und Gnome – mit gtk3-Unterbau viel zu langsam

Einer meiner treuen Begleiter war Libreoffice Draw. Aber nach dem Upgrade auf Opensuse Leap 15 hatte ich damit beinm Arbeiten mehr Frust als Lust. Ich muss z.Z. Skizzen einer Art neuronaler Netzwerke erstellen. Da kommen mal schnell 50 bis zu über hundert Einzelobjekte zusammen, die in großer Anzahl durch "Verbinder" aneinander gekoppelt werden müssen.

Das aktuelle Draw der Libreoffice Versionen 6.0 und 6.1 ist unter einem KDE-System mit GTK3 (Start im Terminal mit "SAL_USE_VCLPLUGIN=gtk3_kde5 libreoffice &") dafür aber viel zu langsam. Klickt man auf das Symbol für "Verbinder" in der Leiste für Zeichnungstools, so dauert es auf hochauflösenden Schirmen (2K bis 4K) und bei komplexen Zeichnungen zwischen 4,5 und 8 Sekunden, bis die Zeichnung auf eine Darstellung mit allen Connector-Punkten der Objekte wechselt. Und ich habe wahrlich kein langsames System; auch die Speichereinstellungen für LO habe ich bereits (mühsam; s.u.) nach oben gesetzt. Während des Darstellungswechsels für Verbinder geht die Belastung des einen CPU-Kerns, den LibreOffice leider nur nutzt, kurzzeitig auf 100%.

Ein Test zeigt, dass die Zeiten bei Einsatz von GTK2 dagegen im Bereich von 2-3 Sek. liegen. Damit kann ich gerade noch leben. Zudem hängt die Geschwindigkeit vom Zoomfaktor ab; kleine und große Zoom-Faktoren machen den Umgang mit Verbindern bisweilen deutlich schneller.

Wer also große Diagramme mit vielen Objekten und Verbindern zeichnen will, sollte im Umgang mit Libreoffice 6.1 auf GTK3 verzichten. Zumindest unter KDE. Das kann man dort entweder durch den Aufruf
SAL_USE_VCLPLUGIN=gtk_kde5 libreoffice &
erreichen, oder aber indem man das Paket libreoffice-gtk3 deinstalliert und dafür das Paket libreoffice-gtk2 installiert (neben libreoffice-qt5). Ein Verzicht auf gtk2 oder gtk3 und eine alleinige Installation von libreoffice-qt5 führt vom Layout her übrigens in die GUI-Steinzeit. Ob das so richtig ist, mag ich im Moment nicht einmal recherchieren.

Nun habe ich auch das Rendern über OpenGL ausprobiert - funktioniert leider nicht => Schwarze Menüs. Ansonsten wäre der Aufbau der Zeichnung selbst etwas schneller ...
Tests unter Gnome und LXDE brachten leider die gleichen Ergebnisse.

Ich hoffe auf Updates - und darauf, dass sich die LO-Entwickler endlich mal Gedanken darüber machen, an welchen Stellen sich Multithreading lohnen würde. Der Umgang mit Verbindern wäre da ein erstes gutes Betätigungsfeld. So wie der Stand im Moment im Zusammenspiel von Draw mit GTK3 aussieht, sind LO 6.0 und 6.1 jedenfalls eine Enttäuschung.

P.S.: Hinzu kommt der sich auch unter Kontact/Kmail ausbreitende Ehrgeiz von Maintainern, bewährte Menüpunkte für Programm-Einstellungen, die die Performance und die RAM-Nutzung einer Applikation beeinflussen, aus dem normalen Menübereich in eine völlig unübersichtliche und undokumentierte globale Parameter-Konfiguration zu verbannen. So geschehen bei Kmail; so geschehen bei LO.

Liebe Leute: Seit wann bieten wir dem User unter Linux weniger Optionen an? Und seit wann wird Bewährtes und Verständliches in der Menüstruktur zugunsten unverständlicher und undokumentierter Parameter-Kaskaden aufgegeben? Bitte liebe LibreOffice-Teams: Hört mit diesem falschen Ehrgeiz an Options-Verlagerung und -Vernichtung auf ... und kümmert euch lieber mal um die Performance.

Libreoffice 6.0 unter Opensuse Leap 15 KDE/ Plasma – GTK3-Stil „Breeze“ macht Probleme

LO ist eine GTK-Anwendung und nutzt in der Version 6.x GTK3. Wie ich kürzlich beschrieben habe, wollte ich u.a. Breeze als GTK3-Stil für GTK-Anwendungen unter Opensuse Leap 15.0 mit KDE/Plasma nutzen. Ursprünglicher Grund war die Suche einer verbesserten, kontrastreichen Darstellung von SWT-Bedienelementen unter Eclipse Photon mit Dark Scheme.

Leider musste ich heute feststellen, dass - zumindest bei mir - der Einsatz von Breeze als GTK3 Style mit der aktuelle Version 6.1.1 von LO zu Problemen führt: Der Scrollbar funktioniert nicht oder nicht immer zuverlässig. Keine Ahnung, was Ursache dieses Breeze-spezifischen Problems ist.

Wer also ein funktionierendes LO 6.1.1 unter KDE/Plasma haben will, sollte also z.B. auf "Adwaita" oder "Ambience" als GTK3-Style ausweichen. Beide Styles funktionieren im Gegensatz zu "Default" auch sehr gut mit dem Dark Scheme Eclipse Photon.

Libreoffice 4.3.5, Opensuse 13.1, langsames Laden von Dateien bei nicht erreichbarem Printserver

Vor einiger Zeit klagten ein Kunde und ein Bekannter von mir darüber, dass sich Libreoffice [LO] beim Öffnen und erstmaligen Laden einer Datei sehr viel Zeit lasse. Wörtlich: Man kann sich erstmal einen Kaffe machen. Diese Meldungen trudelten bei uns sowohl für Windows- wie auch Linux-Systeme ein.

Ich konnte das zunächst nicht glauben; der Effekt ließ sich in unserem Netzwerk auf keinem PC oder Laptop (weder unter Opensuse 13.2 noch unter Opensuse 13.1) nachvollziehen.

Nun war ich vor kurzem ein paar Tage mit meinem Laptop (Opensuse 13.1 mit LO 4.5.3) unterwegs und musste selbst unter dem beschriebenen Problem leiden. Es dauerte einige Zeit, bis ich herausfand, was die Ursache war:

Ist

  • der Druck unter Linux oder Windows für einen Server konfiguriert
  • und wird für die Kommunikation zum Server z.B. das ipp-Protokoll eingesetzt
  • und ist irgendeine Netzwerkkarte aktiv, aber der aktuell eingestellte Druckerserver über das Netz nicht erreichbar,

so wartet Libreoffice zunächst minutenlang vergeblich auf Antworten von dem nicht zu findenden Drucker-Server, bevor es anfängt den Inhalt einer zu ladenden Datei zu rendern.

Ist dagegen ein Druckerserver oder ein lokaler Drucker erreichbar oder aber überhaupt kein Netzwerk aktiv, so öffnet LO die zu ladenden Dateien ohne Zeitverlust. In unserem Netz übernimmt ein permanent erreichbarer CUPS-Server die zentrale Ansteuerung verschiedener Druckerwarteschlangen; deshalb war das Problem auf Systemen innerhalb unseres Netzwerkes nicht nachvollziehbar.

Das Ganze ist natürlich für Libreoffice wenig werbewirksam. Liebe Libreoffice-Entwickler: Es soll tatsächlich Leute geben, die sich mit Ihrem Laptop zwischen verschiedenen Netzen daheim und am Arbeitsplatz bewegen - und manchmal ist halt keiner der eingestellten Drucker oder Druckerserver erreichbar, obwohl man z.B. an einem WLAN hängt. Dann sollte man nicht 3 bis 4 Minuten warten müssen, bevor eine simple Calc-Datei geladen wird.

Ein Workaround besteht bei Bedarf darin, die Druckereinstellungen (temporär) so umzustellen, dass erst gar nicht nach einem Netzwerkdrucker gesucht wird. Unter Linux ist das relativ einfach - unter Windows muss man sich durch die entsprechenden Punkte der Systemsteuerung quälen und die eingestellten Netzwerkdrucker entfernen. Das Dumme ist, dass man bei Rückkehr ins heimische Netz die Netzwerkdrucker wieder in den lokalen Druckeinstellungen aktivieren muss.

Ich denke, die Libreoffice-Entwickler haben hier wirklich etwas zu korrigieren. Es ist für Leute, die sich mit ihren Laptops evtl. täglich zwischen verschiedenen Arbeitsplätzen und Netzwerken hin und her bewegen müssen, nicht zumutbar, ihre Druckereinstellungen laufend anpassen zu müssen. Das Fehlen oder die Nichterreichbarkeit eines Druckerservers oder Druckers sollte nicht zum vollständigen Stopp des Datei-Ladens und -Renderns führen. Besser wäre hier ein Dialog, in dem der User über das Suchen nach dem Druckerserver informiert wird und ggf. diesen Schritt auch überspringen kann.

Hofen wir mal, dass das Problem mit einer der nächsten LO-Versionen wieder verschwindet.