GTK(mm) zu langsam unter Windows?



  • Hi,

    wie der Titel schon sagt habe ich das Gefühl, dass die Laufzeitgeschwindigkeit von Gtk(mm) unter Windows recht langsam ist. Damit meine ich, dass neuzeichnen der Anwendung, wenn man z.b. ein Fenster über der Anwendung hin und her ziehe dauert es doch recht lange bis die Anwendung ihren Inhalt wieder neu darstellt. Unter Linux bzw. GNOME besteht das Problem nicht. Mich würde interresieren ob das normal ist, bzw ob das bei anderen GUI Kits unter windows auch solche probleme haben? Oder ob ich nur das Problem habe (oder auch sehe). Also ob das generell ein Problem von Andwendungen ist welche nicht Nativ mit der WinAPI geschrieben wurden.
    Die Frage ist nun ob es Optimierungsmöglichkeiten gibt, die Laufzeit zu verbessern oder ähnliches?

    Mfg Linuxpower


  • Mod

    Hm, das muss nicht zwangsläufig an GTKmm liegen, das kann auch an anderen Dingen hängen.
    Wie z.b. sieht dein Code aus? Hast du die aktuellste GTK(2.0) Version für Windows installiert? etc.



  • Also das Programm läuft bis jetzt mit Gtk 2.8.18, Gtkmm 2.8.8 und übersetzt wurde es mit mingw 3.4. Also das Programm ist z.b. nicht mit Glade geschrieben (ich denke mal, dass Glade die Ausführungszeit doch schon beinflusst oder?). Sondern eben nativ die eigene Klassen für die Widgets erstellt (eben von Gtkmm vererbt). Aber eigentlich kann doch das neuzeichnen des GC nicht sooo sehr vom Code abhängen oder?



  • Hallo,

    ja, in der Tat, gtkmm ist unter Win ziemlich lahm. Frag mich nicht warum. Vermutlich mangelnde Erfahrung der Entwickler über die Windows-Plattform. Gelegentlich haut dir gtkmm unter Win auch eine Exception unter die Ohren, die du unter Unix nicht kriegst.
    Z.t. schlecht umgesetzt.

    Linuxpower schrieb:

    (ich denke mal, dass Glade die Ausführungszeit doch schon beinflusst oder?)

    Nicht notwendigerweise.

    Die möglichkeiten für die Optimierung sind eher begrenzt, du könntest halt sowas wie "Lazy Evaluation" anwenden, d.h. Teile der Anwendung erst laden, wenn sie der Benutzer wirklich braucht. Dann muss er dafür zwar etwas warten, aber die Basis-Applikation ist schneller da. Hängt halt davon ab, wie deine Applikation aufgebaut ist.

    Ansonsten hilft nur, gtkmm selbst zu kompilieren und entsprechend diese DLLs anstatt der Standard-DLLs zu verwenden.

    MfG

    GPC



  • ALso das Phenomen kann man auf jeden Fall unter GIMP beobachten. Ich kenne es von GIMP auch nicht anders, das sich das repainting verzögert aufbaut. Ich vermute mal, es liegt an der Grafiklib, die GTK benutzt. Es gibt ja diverse platformübergreifende Grafiklibs (wie Cairo und noch so ne andere beliebte, Name ist mir aber entfallen), die alle unter Windows um einiges langsamer als die GDI sind. Der Vorteil der GDI und GDI+ ist nunmal, das diese hardwarebeschleunigt sind. ABER, das sollte GTK-Programme eigentlich nicht hindern, das das repainting besser funktionieren sollte. Vielleicht hat GTK unter Windows keinen Backbuffer?



  • Artchi schrieb:

    Der Vorteil der GDI und GDI+ ist nunmal, das diese hardwarebeschleunigt sind.

    Cairo eigentlich auch, oder?

    Vielleicht hat GTK unter Windows keinen Backbuffer?

    Dadurch würde es ja eher schneller werden, bzw. flimmern.

    mfg.



  • Cairo eigentlich auch, oder?

    Laut FAQ von Haus aus nicht. Erst wenn man glitz hat. Aber ich steig bei den Linux Libs eh nicht durch.
    Ganz unten: http://cairographics.org/FAQ

    Dadurch würde es ja eher schneller werden, bzw. flimmern.

    Nö, eigentlich soll ein Backbuffer die Performance erhöhen. 😃 Weiß ja nicht wie das heute ist, aber damals war es nötig Backbuffers anzulegen, teilweise sogar zwei (!), damit es schneller geht. Aber wie gesagt, vielleicht hat sich die Grafik-Technik auch um 180° gedreht und ich habs nur nicht mitbekommen. 😉



  • Artchi schrieb:

    Cairo eigentlich auch, oder?

    Laut FAQ von Haus aus nicht. Erst wenn man glitz hat. Aber ich steig bei den Linux Libs eh nicht durch.
    Ganz unten: http://cairographics.org/FAQ

    Ich glaub damit meinen die eher 2D-Beschleunigung wie DirectDraw, so schnell bist du ja auch mit GDI nicht, oder?
    Und glitz ist für OpenGL, das ist ja noch was ganz anderes, sowas hat man ja auch bei der GDI nicht.

    Aber ich steig bei den Linux Libs eh nicht durch.

    Englische Wikipedia ftw 😉

    mfg.



  • Die GDI ist hardwarebeschleunigt. Vorausgesetzt der Grafikchip und Treiber bieten das an. Was aber nicht ungewöhnlich ist. Es gibt sogar von Intel Notebook-Grafikchips, die GDI+ beschleunigen. Ob die Beschleunigung mit D3D mithalten kann, ist dann ein anderes Thema. Es geht ja erstmal prinzipiell um Beschleunigung durch Hardware.



  • Artchi schrieb:

    Die GDI ist hardwarebeschleunigt. Vorausgesetzt der Grafikchip und Treiber bieten das an. Was aber nicht ungewöhnlich ist. Es gibt sogar von Intel Notebook-Grafikchips, die GDI+ beschleunigen. Ob die Beschleunigung mit D3D mithalten kann, ist dann ein anderes Thema. Es geht ja erstmal prinzipiell um Beschleunigung durch Hardware.

    Ja, aber diese Hardwarebeschleunigung ist ja noch was anderes als z.B. DirectDraw es hat, oder?

    mfg.



  • Also die Details kenne ich nicht. Aber du hast doch ab Win2000 Pro schon Fenster mit Alphablending, du kannst Fenster animieren, mit Slides, Expansion oder Fade-in-out. (sieht man nur selten, weil die meisten GUI-Apps noch unter Win98 laufen wollen) Der gesamte Desktop ist ja GDI, bis einschliesslich WinXP. Eine gewisse Beschleunigung ist also durch die Grafikchips da. DirectDraw wiederrum hatte damals den 3D-Chip genutzt, naja, so kenne ich das jedenfalls von der Dreamcast. Da hatten wir DirectDraw unter DX6 genutzt, und DD war dann volle 3D-Beschleunigung, obwohl 2D-API. Ist auf dem PC sicherlich auch der Fall. Also ist dei GDI-Beschleunigung eine andere als die von DirectDraw.

    Ab Vista ist alles nochmal ganz anders. Da wurde ja alles geändert. Ein ganz anderes Thema. 😉

    Aber am Ende stellt sich die Frage, wie Libs wie Cairo verfahren? Wenn diese den Anspruch haben, unter jeder Platform das gleiche grafische Ergebnis zu haben, dürften sie keine GDI-Funktionen wrappen. Z.B. ein Farbverlauf könnte unter Windows anders aussehen, als unter Linux. Weil die GDI wahrscheinlich ein anderes Ergebnis bringt. Also kann ich mir vorstellen, das Cairo und Co. eigene Algorithmen haben, damit das Ergebnis überall gleich aussieht. Aber dann darf man keine GDI benutzen. Zumindest nicht für komplexere Effekte. Einen Pixel setzen, eine Linie ziehen... das sind primitive Funktionen, die kann man/muß man von der GDI nehmen.

    Das sind aber alles nur Mutmassungen von mir.


Anmelden zum Antworten