Gnome 2.12 extrem langsam

J

juedan

Guest
Hallo an alle,

auf meinem Rechner ist Gnome 2.12 unter FreeBSD 5.4 extrem langsam:
  • Aufklappen von Menüs dauert zwei bis drei Sekunden
  • Scrollen in einer Liste: man kann zusehen, wie die einzelnen Listenelemente dargestellt werden
  • Seitensweises Scrollen von Text im Editor gedit unerträglich langsam. Es dauert fünf Sekunden bis der neue Textausschnitt dargestellt wird.
  • Die Darstellung in einem GnomeTerminal ist extrem langsam.
Um es gleich vorwegzunehmen: Es liegt nicht an der Netzwerkkonfiguration. localhost und die lokale Adresse sind zu erreichen. Auch der Start des Gnome-Desktop geht innerhalb von zehn Sekunden ziemlich flott voran.

Hat noch jemand einen Tip, wo ich suchen könnte? Unter Gnome 2.8 war diese Langsamkeit nicht zu beobachten.

Vielen Dank schon mal für die Hinweise.

Viele Grüße

Jürgen
 
Hallo Jürgen,

es hilft dir zwar nicht viel, aber ich kann dir deine Feststellung (leider) nur bestätigen.. Ich hatte mir diese "Verzögerungen" beim Gnome-Update von 2.10 nach 2.12 auch implementiert. "Hatte", weil ich das Problem auch nicht auf die Schnelle lösen konnte und daher wieder mein Backup zurückgespielt habe. Ich werde gegenwärtig bei Gnome 2.10 bleiben.

Trotzdem einen tollen Tag!

Greetz Marcel
 
Hi,

ich bin kein Gnome-User und habe auch keine Ahnung davon. Ich nutze KDE.
Ich hatte soetwas ähnliches beim Aktivieren von Tranzparenzen. Danach war die 2,5GHz Kiste mit 1GB Ram und ATI Radeon 9700 'unbrauchbar'.

Gruß c.
 
Das ist ein Schuss ins Blaue: 2.12 benutzt, im Gegensatz zu 2.10, cairo zum Darstellen der Fenster.

Cairo sollte OpenGL zur beschleunigten generierung von (Darstellungs)Elementen benutzten. Eventuell ist dort "irgendwo" das Problem zu suchen.
 
Moin @all,

danke für die Antworten.
Mittlerweile hat sich folgendes herauskristallisiert:
  • Das Phänomen tritt nur bei jedem zweiten oder dritten Start des Systems auf:eek:
  • Da der Betrieb von Applikationen unter twm deutlich performanter ist, vermute ich connectivity-Probleme zwischen GTK2 und den X-Libs bzw. X-Server
  • Nachdem ich den "DBUS" aktiviert hatte, war ein Geschwindigkeitsschub deutlich spürbar
Aber gerade die Punkte 1 und 2 stören mich gewaltig. Noch dazu hatte ich diese Schwierigkeiten schon unter Gnome 2.8. Damals war ich im Gespräch mit den Entwicklern, aber irgendwie ist alles im Sande verlaufen.

Die Sache mit "Cairo". Ich hatte auch schon daran gedacht, dass da die OpenGL-Erkennung nicht sauber funktioniert. Ich habe keine OpenGL-fähige Grafikkarte und werde mir auch keine anschaffen, da ich mit meiner Matrox G450 PCI sehr zufrieden bin.

Vielen Dank nochmals für die Antworten

Jürgen
 
Hallo thyrver,

die Sache mit Cairo habe ich woanders gelesen. Das scheint der Knackpunkt zu sein.
ABER: KDE 3.4 läuft genauso lahm. Dort ist das Fontrendering sogar noch langsamer...

Aber gut, ich werde Gnome 2.10 testen. Da es auch für unsere Kunden wichtig ist, werde ich mit wohl gute Argumente einfallen lassen müssen, dass die ihre "alte" Hardware zum Müll schicken. Denn selbst auf 2GHz-Maschinen ist das Teil so grotten langsam, dass man sich in die Zeiten eines Schneider PCs zurückversetzt sieht. Schön, dass man M$-Windows sogar in dieser Beziehung nachmacht.

Viele Grüße und schönen Abend

Jürgen
 
@juedan: Leider setzt sich das bis in die von GNOME/GTK abhängigen Programme fort. Geht man auf die Glib/GTK-Seite http://www.gtk.org/, stellt man ständige Updates/Upgrades fest. Das wäre an sich nicht schlimm, wenn es der Stabilisierung der Sachen dienen würde. Meist wird aber dieser Schnick und jener Schnack noch zusätzlich eingebaut, schattierte Fensten, Transparenz, Mama sagen und Männchen machen muß es auch noch können.
So richtige Alternative zu den "Großen" gibt es kaum. Xfce4 setzt auch auf GTK2 auf, wäre noch Enlightenment (das neuere, wenn es mal fertig ist) oder der gute alte Windowmaker für alle, die es nicht gar so spartanisch mögen. ROX ist wieder auch mit GTK2 verbunden: zum Mäusemelken.
Ich bin zu XFree86 zurückgekehrt, was etwas mehr Performance mit sich brachte. Vielleicht können sich ja Deine Kunden mit einer Kombination aus XFree und Windowmaker anfreunden? Wenn man letzteren richtig einrichtet (mehr Arbeitsaufwand), ist er eine gute Alternative.
Tschuldigung, wenn ich hier Dampf ablasse, dennoch: mit einem Dual-Pentium-II-Rechner, 512MB Arbeitsspeicher, einer ordentlichen Matrox G400 AGP dachte ich auf der sicheren Seite zu sein, und es will mir nicht in den Kopf, alle Jahre wieder meine Hardware aufzurüsten.
Kann man da nichts machen? Die Entwickler solcher Anwendungen (Ehre für Ihre unermüdliche freiwillige und kostenlose Arbeit) wollen doch sicher gute Sachen erstellen? Schön wäre es, von dem ganzen GTK- Und QT-Gelumpe wegzukommen... Na, hilft Dir sicher nichts, meine Maulerei. Ich suche auch nach einem Ausweg.
 
Hallo.
Ich würde das sehr gerne mal ausprobieren, bekomme Gnome allerdings nicht mal zum laufen, weder 2.10 noch 2.12.
Aber wenn ich das hier so lese, bleib ich doch lieber bei meinem Fluxbox.
;'(
 
@ juedan: Gratulation zum 1000. Beitrag.

@ Lemony Snicket: Wenn du gnome doch zum Laufen bringen willst, dann mach bitte einen eigenen Thread auf und poste da genauer was nicht funktioniert.

ontopic: Wenns für einen Haufen Produktivsysteme ist: Scheinbar kann man Metacity so kompilieren, dass diese zusätzlichen GTK-Features nicht verwendet werden. Das scheint nicht sonderlich gut dokumentiert zu sein.

ad toolkit-bashing: Ich brauch auch eher eine funktionelle und schnelle Oberfläche, als Schatten und Transparenz. Cairo ist allerdings trotzdem ein Schritt in die richtige Richtung, den OpenGL überträgt nunmal Arbeit vom Prozessor auf die Grafikkarte, und dort ist diese Arbeit besser aufgehoben. IMHO selbstverständlich.

Die g450 von Matrox sollte übrigends openGL können.
 
Hallo I18n,

man und ich dachte, ich wäre der einzige, der einen riesen Bissen von der Tischplatte genommen hat.
Das mit XFree86 hatte ich mir auch schon überlegt, aber ich habe keinen Bock alle Pakete zu kompilieren und beim letzten tritt ein Fehler auf und alles war für die Katz. Packages mit XFree86-Abhängigkeit gibt es leider nicht - speziell OpenOffice!!!

Ich werde jetzt Gnome 2.10 ausprobieren, wenn das auch nicht rennt, muß ich mir allen Ernstes mal so richtig Gedanken machen, was dann. Ich muß das ggü. meinen Kunden und Firma vertreten undbegründen können. Mir persönlich würde twm reichen, aber dem Windows-verwöhnten Menschen????

Grüße

Jürgen
 
Hallo tyrver,

1000. Beitrag? Uups ist mir nicht aufgefallen...

d toolkit-bashing: Ich brauch auch eher eine funktionelle und schnelle Oberfläche, als Schatten und Transparenz. Cairo ist allerdings trotzdem ein Schritt in die richtige Richtung, den OpenGL überträgt nunmal Arbeit vom Prozessor auf die Grafikkarte, und dort ist diese Arbeit besser aufgehoben. IMHO selbstverständlich.
Zum Vergrößern anklicken....
Dass Cairo wichtig ist, kann ich jetzt noch nicht beurteilen. Aber ich denke, dass das Font-Rendering - sehr wichtig, damit Schriften performant und sauber dargestellt werden - nicht durch OpenGL-Funktionen erledigt werden sollte, sondern durch hochoptimierte Funktionen im Fontserver, die von JEDEM Toolkit erreichbar sind.
Die Reibungsverluste zwischen den APIs und Plausibilitätsprüfungen kosten einfach zuviel Rechenleistung. Schließlich will der Anwender auf die Darstellung einen Menüs nicht warten, sondern er will sie sehen!
Ganz einfache Frage, was ist, wenn die Grafikkarte oder der Treiber keine OpenGL-Unterstützung bereitstellt?

Das Fontrendering im 2D-Bereich schnell sein kann, hat ja Gnome 2.8 bewiesen. Das läuft ganz toll auf meinem Notebook (PII-266MHz).

Aber mei, wenn man einem Windows XP/Vista unbedingt nacheifern muß. Für Büroanwendungen ist "Transparenz" sowas von sch... egal. OpenOffice braucht kein OpenGL!

Nun ja, back to Gnome 2.10

Viele Grüße

Jürgen
 
Hallo Leute!

Also ich muss mich jetzt hier mal einklinken...

Ich habe hier Maschinen auf den läuft gnome seit den frühen 2.x Versionen (PIII-800MHz). Bis gnome 2.10 unter FreeBSD 4.11-STABLE und ab gnome 2.12 unter FreBSD 6.0-STABLE.

Seither wurden mit jeder Version Fehler korrogiert und Teile erneuert, wobei seit gnome 2.10 ein sehr ausgereiftes und robustes DE angeboten wird.

In Sachen Geschwindigkeit kann ich sagen, dass es durch die verschiedenen Versionen eigentlich immer besser wurde oder zumindest gleich blieb. Auf den Maschinen hier kann man sehr gut und absolut flüssig arbeiten.

Allerdings muss ich sagen, dass ich immer nur den gnome-Kern installiere (gnome2-lite) und alles weitere nur was gebraucht wird.

Also ich kann eure Pauschalaussagen zum "extrem langsamen Gnome 2.12" nicht teilen.

Grüße
-MadMax
 
Hallo Jürgen,
bislang hatte ich mit der Kompatibilität zu xorg keine Probleme, ein einfaches X_WINDOW_SYSTEM=xfree86-4 in die make.conf, und alle Ports bauen auf XFree86 auf.
Wenn man OpenOffice.org aud den Packages installiert, gibt es zwar Fehlermeldungen wegen xorg während der Installation, es läßt sich aber fehlerfrei nutzen. Die entsprechenden von OO benötigten Anwendungen aus xorg werden einfach durch die von XFree86 ersetzt.

Was Fonts betrifft, verstehe ich auch nicht, wieso diese mit OpenGL gerendert werden müssen. Ein wirklich gutes Konzept habe ich mal bei QNX gesehen: Strichfonts. Sprich: Vektoren. Das macht sich besonders bei so komplexen Schriftzeichen wie beim Chinesischen/Japanischen hervorragend, die Schriften sind angenehm skalierbar, selbst kleinste Fonts sind noch gut lesbar -- und sie benötigen nur ein paar hundert Kilobyte Speicherplatz, werden dementsprechend schnell in den Arbeitsspeicher geladen. Erst beim Drucken wird die entspr. Bitmap-/Postscriptschrift geladen. Habe ich woanders noch nie gesehen.
BeOS bietet ebenfalls ein gutes Konzept, die Schriften werden selbst auf alten Maschinen rasend schnell geladen, da sind sie von hervorragender Qualität. NeXtSTEP hatte auch ein gutes Konzept, alles war Postscript. Ich weiß nicht, warum man immer wieder das Rad neu erfinden muß!?

Als Alternative zu KDE/GNOME kann ich Windowmaker wirklich wärmstens empfehlen, oder, wenn es wirklich so Windows-ähnlich werden soll, rox-session ist dafür gut geeignet. Ich habe es lang genutzt, schnell und sehr leicht zu konfigurieren. Es muß ja nicht immer Fluxbox sein ;)
Allerdings, Kundenwünsche sind Kundenwünsche. Ich hab mal Windowmaker windowsverwöhnten Freunden gezeigt, einige zeigten sich von dem durchdachten Konzept begeistert, einer arbeitet noch heute damit und will es nicht mehr missen.
 
juedan schrieb:
ABER: KDE 3.4 läuft genauso lahm. Dort ist das Fontrendering sogar noch langsamer...
Zum Vergrößern anklicken....
Da glaube ich dann aber doch eher, daß was mit deiner Installation nicht in Ordnung ist. Vor etwa zwei Wochen habe ich (mehr aus Spaß) FreeBSD 6.0-RELEASE mit KDE 3.4.2 auf einem UltraSPARC IIi 360 MHz mit einer ATI 3D Rage Pro installiert. Wenn der KDE-Trümmer erst mal geladen ist, geht alles ruckzuck, obwohl die Hardware nicht unbedingt der Renner ist. GIMP, gegen GTK2 gelinkt, läuft auch sehr geschmeidig.

Und MadMax hat ja auch keine Probleme mit seinem GNOME. Vielleicht kannst du mal eine ganz frische Installation mit einem 6.0-RELEASE in einer Testumgebung aufsetzen, ohne irgendwas groß dran zu konfigurieren, und dann noch mal GNOME 2.12 antesten.

EDIT: Nur so eine vage Vermutung, aber hast du schon mal sämtliche(!) Fonts-Caches mittels fc-cache(1) neu gebaut?
 
Zuletzt bearbeitet:
Hallo 0815Chaot,

danke für den Tip, aber FreeBSD 6.0 läuft nicht auf meinem Rechner. Es gibt Probleme mit den SymBIOS-Treibern beim Scannen des SCSI-Busses. Ich knn FBSD 6.0 schon gar nicht mehr installieren, um es aktualisieren zu können.

Viele Grüße

Jürgen
 
Hallo I18n,

Was Fonts betrifft, verstehe ich auch nicht, wieso diese mit OpenGL gerendert werden müssen. Ein wirklich gutes Konzept habe ich mal bei QNX gesehen: Strichfonts. Sprich: Vektoren. Das macht sich besonders bei so komplexen Schriftzeichen wie beim Chinesischen/Japanischen hervorragend, die Schriften sind angenehm skalierbar, selbst kleinste Fonts sind noch gut lesbar -- und sie benötigen nur ein paar hundert Kilobyte Speicherplatz, werden dementsprechend schnell in den Arbeitsspeicher geladen.
Zum Vergrößern anklicken....
So kenne ich das auch von AdobeType1-Fonts. Die setzen sich ausd Splines zusammen, die mittels superschneller Polynomberechnung zwischen den Stützpunkten erzeugt werden. Schade, dass es für das X-Window-System kein Display-Postscript gibt... Das wäre eine tolle Sache.

Viele Grüße

Jürgen
 
Hallo @all,

zum Thema "Gnome 2.12" hatte ich gestern mit einem der XOrg-Entwickler ein längeres Telefonat. Er hat mir empfohlen, dass auf etwas langsameren Systemen unbedingt folgendes zu beachten ist:
  • in /boot/loader.conf das Grafiktreibermodul eintragen, z.B. "load_mga="YES" für Matroxkarten
  • in /etc/X11/xorg.conf diesen Eintrag vornehmen unter besonderer Beachtung des Mode-Abschnitts!
    Code: 
    Section "DRI"
	Mode 0666
EndSection
  • für Gnome ab 2.12 unbedingt "dbus" aktivieren
  • einen Geschwindigkeitszuwachs kann auch diese globale Variable bringen:
    Code: 
    GDK_USE_XFT=0|1
  • Manchmal kann es vorkommen, dass beim Login über gdm keine Eingabe möglich ist. Wir haben die Erfahrung gemacht, das ein Startskript wie das folgende sehr gute Dienste leistet:
    Code: 
    #!/bin/sh
#
# $FreeBSD: ports/x11/gdm/files/gdm.sh.sample,v 1.1 2005/01/24 23:26:23 pav Exp $
# 
# Start-Skript: /usr/X11R6/etc/rc.d/xserver.sh
# erstellt: 20.01.2006
# Aenderungen:
# 21.02.2006: Sprachumgebung auf "deutsch" umgestellt
# =====================================================================

PREFIX=/usr/X11R6

case "$1" in
start)
	echo -n "starting gdm ..."
	export LANG=de
	export LANGUAGE=de
	export LC_CTYPE=de_DE.ISO8859-15
	export LC_ALL=de_DE.ISO8859-15
	sleep 5
	${PREFIX}/bin/gdm
	;;
stop)
	/usr/bin/killall -m gdm 2>/dev/null
	;;
*)
	echo "Usage: `basename $0` start | stop"
	exit 64
	;;

esac

exit 0
    Wichtig scheint der sleep-Befehl zu sein. Der gibt den ttys Zeit, sich zu initialisieren.
    Das Skript sollte einen Namen bekommen, der es erst sehr spät startet: z.B. /usr/X11R6/etc/rc.d/xserver.sh
Auf unserer Testmaschine hat es einen deutlichen Geschwindigkeitszuwachs gebracht. Das Phänomen, dass Gnome mal schnell und mal wieder langsam war, ist verschwunden, seit das MGA-Modul über die /boot/loader.conf geladen wird. Auch ein Login ist wieder problemlos möglich.

Viele Grüße

Jürgen

PS: Ich werde das im Wiki eintragen.
 
juedan schrieb:
Hallo I18n,


So kenne ich das auch von AdobeType1-Fonts. Die setzen sich ausd Splines zusammen, die mittels superschneller Polynomberechnung zwischen den Stützpunkten erzeugt werden. Schade, dass es für das X-Window-System kein Display-Postscript gibt... Das wäre eine tolle Sache.

Viele Grüße

Jürgen
Zum Vergrößern anklicken....

Hm, ich meinte ein etwas anderes Konzept. Type1 sind Flächenvektoren, sprich. eine Fläche wird durch Eckpunte und verbindende Kurven brechnet. QNX arbeitet mit Strichen, die definiert werden: zeichne eine Kurve von A nach B mit n Dicke.
Im Druck werden die Fonts dann mit entspr. TrueType- bzw. Type1-Fonts ersetzt.
 
juedan schrieb:
zum Thema "Gnome 2.12" hatte ich gestern mit einem der XOrg-Entwickler ein längeres Telefonat. Er hat mir empfohlen, dass auf etwas langsameren Systemen unbedingt folgendes zu beachten ist:
  • in /boot/loader.conf das Grafiktreibermodul eintragen, z.B. "load_mga="YES" für Matroxkarten
Zum Vergrößern anklicken....


  • Hm, ich habe
    Code: 
    device          agp             # support several AGP chipsets
device          drm
device          mgadrm          # 3D-Beschleunigung fuer Matrox G400
    beim Kernelbau eingetragen, sprich, die Matrox wird direkt über den Kernel über AGP angesprochen. Zudem wird DRM geladen, um DRI ansprechen zu können. Besagte Eintragung habe ich auch in die XF86Config gemacht, dennoch gibt es Schwierigkeiten z.B. mit OpenGL: Blender machst sehr ulkige Sachen, das Gitter flackert in der Darstellung, die Menüs sehen verzeichnet aus usw. bei OpenOffice habe ich tunlichst OpenGL ausgeschaltet.
    Wie ich meine, sollte der feste Einbau in den Kernel dem Laden des Moduls vorzuziehen sein, oder?

    PS:
    # für Gnome ab 2.12 unbedingt "dbus" aktivieren

    Wie meinst Du das? Wo wird der aktiviert? Im Kernel?
 
Hallo i18n,

so wie es mir der Entwickler mitgeteilt hat, sollte auf langsamen Systemen das Modul geladen werden und nicht in den Kernel eingebaut sein. Bei der Begründung hat er sich etwas schwammig ausgedrückt: Durch das Laden des Moduls würden die Resourcen für die Grafikkarte schon vor dem Laden des Kernels reserviert sein.

Der DBUS ist in der /etc/rc.conf zu aktivieren. Der zugehörige Daemon wird automatisch mit Gnome 2.12 zusammen installiert.
Code: 
# DBUS-Daemon
# dbus_enable="YES"

Viele Grüße

Jürgen
 
Hi,

auch bei mir gibt es diese lästigen Verzögerungen - Rechtsklickmenüs brauchen sehr lange bis sie erscheinen, die Logout-Dialog-Box läßt Minuten auf sich warten.
In etwas weniger schlimmer Art ist dieses Verhalten auch auf einer ubuntu Linux Installation zu beobachten.

Die hier vorgestellten Tips haben leider nichts gebracht, aber vielleicht gibt's ja noch mehr Ideen.

FreeBSD 6.0, auf 6.1 PRERELEASE upgraded, alles aus den ports gebaut.
Parameter in der make.conf:
Code: 
CPUTYPE?=athlon-xp
Macht Sinn denke ich da in meiner Kiste ein Athlon XP 2500+ werkelt.
Code: 
CFLAGS= -O2 -pipe
Alle makes sind ohne Probleme durchgelaufen, das System scheint mir auch sehr stabil und bis auf die Probleme/Verzögerungen in gnome recht flott zu arbeiten.
Ich werd mich sicherlich auch noch umschauen ob's noch irgendwelche genialen Parameter oder dergleichen gibt...

Cheers

tcs
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben