Ускоряване на Linux GUI. Възможно ли е?

Според вас на какво се дължи GUI-то да е бавно? Когато променя размера на прозорец , всички дъщерни прозорци също се пречертават но прекалено бавно. На какво се дължи и как може да се подобри тази работа? Почвам да си мисля , че не е от X а е от управителя на джамове. Тоест явно малко късно изпраща PAINT съобщение или какъвто е там аналога. Препоръчайте ми wm който не да е лек:-) а да е бърз. Или това е съвсем невъзможно да се подобри? Сложил съм драйвер на nvidia => не е в липса на 2d графично ускорение проблема.

hm..ia dai malko poveche info...ne mi se e sluchvalo takova neshto i mi e interesno..kakvo za teb e ¨prekaleno bavno¨ sashto ne mi e iasno..s kva nvidia si i kav driver??

Ползвам модула "nv" (който си върви с x.org). Не съм инсталирал допълнително драйвери. Не забелязвам проблеми с 2D графиката. Ползвам KDE 3.4.0, Xorg 6.8.2. Желязото ми е nVidia Vanta 16MB:

root@darkstar:/home/valentin# lspci | grep nVidia
01:00.0 VGA compatible controller: nVidia Corporation NV6 [Vanta/Vanta LT] (rev 15)
root@darkstar:/home/valentin#

2D ускорението е перфектно при модула nv (казват, че са го писали от фирмата производител).

[линк]

Бавно е когато времето за реакция е поне и над 1/4 сек. Тоест има видимо забавяне. Версия на драйвера ами нямам идея. Последния драйвер от сайта на нвидиа. Картата е GeForce2 440 или нещо такова. Картата си перка екстра гледам фашта по 50 - 70 fps тук там:)). Дистрото е Suse 9.3 pro. Не е да няма памет повече от половината е винаги свободна. Същата история преди време на slack 9.1 май и на radeon 9700 ама след като му се качи драйвер се пооправи.

Ще взема да направя опит да видя как е с "nv" и ако е същото пак се връщам на "nvidia"

i az mislq che e neshto s windowmanager-a. samo deto ne razbiram situaciqta. kakwo sa podprozorci? nqkakwo mdi view li imash? togawa sigurno e normalno da poluchat PAINT. koq programa i koj windowmanager stawa duma? naj-weroqtno, this bug is by design, deto se wika.

ima neshto gnilo ama sha triabva da liagam che pri men e 3 i 20 am..ama tova deto go pishesh neshto ne se varzva...malko veroiatno e i pri razlichni distrota i pri razlichni karti da go imash vse sashtia problem.....ia si poogledai compira ..pisha malko na izust shtoto ne sam polzval Suse ot neznam koga i niamam ideia 9.3 kvo e, a i nikoga ne sam polzval ATI

metacity/xfcewm/icewm ще пробвам и с twm:)) . За всички е видимо забавяне при прерисуване породено от мащабиране или най-общо от оразмеряване. Само за пример видимо е със сигурност при anjuta. Сигурен съм че коя да е програма също е на това дередже:)). С anjuta спретнах едно малко програмче с прозорец и с таб контрола която е по размера на главния прозорец. Когато оразмеря главния , таб контролата и тя се оразмерява ... след време. Изглежда се задейства закона за еластичноста:))

Компютрите са напълно различни. Само собственика им е един и същ:))

malko qsnowidstwo:
polzwash gtk, i po-specialno GtkNotebook widget-a.
bih probwal
[линк]
[линк]
wiv i
[линк]
move bi movesh da swurvesh callbackowete po po udachen nachin. move prosto neshto gui-builder-a ti da ne go prawi optimalno. obache naj-weroqtno taka si e proektirana gtk bibliotekata i po-specialno toq widget.

мopaв, не мога да разбера какво точно имаш предвид и къде и как го забелязваш.
Предполагам, че питаш за това което ще кажа по-долу.
Та, ако сравняваш GUI на Linux и на Windows, трябва да се признае, че GUI на Win е по-бърз. Правени са тестове с Pro/ENGINEER и са сравнени различни дистрибуции на Linux и Windows. Причината е, че графичната среда на Linux работи на принципа клиент-сървър, докато при Win не е така. Така, че е нормално GUI задачите за се решават по-бавно.

Стана въпрос за nv и nvidia модулите. Правилото е следното: ако НЕ ползваш 3D, използвай nv модула. Той е изключително стабилен и перфектен в 2D. Няма какво да се лъжем nvidia има доста бъгове, макар да се работи много усилено по него.
Аз също ползвам nvidia, но защото ми трябва 3D, иначе не бих го сложил.
За WM ползвам Fluxbox. Почти на 100% е вярно правилото: малък wm => бърз wm. Може да пробваш hackedbox, ако не си го пробвал, но е доста орязан за ежедневна работа, но става, ако не обичаш шаранийката.
Аааа, една забележка:
"Сложил съм драйвер на nvidia => не е в липса на 2d графично ускорение проблема."- Не бъркай двата щата.

доколкото съм чел е динамичното свързване.

В Linux (по-точно в .so модела) функциите от библиотеките се викат директно, което означава, че на всяко място, на което се вика такава функция, по време на зареждане трябва да се попълни адреса на нужната функция от заредената библиотека. Това отнема доста време при начално стартиране, но прави кодът след това малко по-бърз.

В Windows извикванията на код от библиотеките са индиректни (през указатели), което изисква много по-малко работа при начално зареждане, затова и една и съща програма под Windows тръгва по-бързо. Цената е, че е малко по-бавна по време на работа.

В Linux има решения на проблема, наречени pre-link, но лично аз нямам опит и не мога да ги коментирам.

В случая обаче ми се струва, че проблемът не идва от това.

ми ако можеш да се справиш със енлайтмънт е17 пробвай :>
малко е бета ма на мен ми върши работа и наистина работи бързо

Life is a bitch. And then you die!

причината е в принципа на х-а

Като са те почнали, и аз в същия дух: fvwm2 би трябвало да е най-бърз

Има доста леки и бързи среди със същият този X.

А и комуникацията клиент-сървър през Unix сокети е много по-бърза от комуникация през IP сокети; да не говорим че има куп ускоряващи техники. Все пак, обикновено не чертаем точка по точка с X, а запълваме региони с шаблон или печатаме текст като шрифта стои в сървъра.

Причината за конкретното бавене е лош (не-използващ хардуерното ускорение) X или нещо друго, не самия X протокол.

винаги се забелязва забавяне, също така се забелязва забавена реакция на мишката и клавиатурата, колкото и да са бързи комуникациите, имаш няколко слоя в повече и то не съвсем безобидни слоеве.

Доколкото рабирам, проблемът е следния:
При промяна на размера на някакъв прозорец/местене на прозорец се предизвиква пречертаване на съдържанието му. При Windows има едно програмче (TweakUI), което може да забрани пречертаването на целия джам. Мисля, че опцията се казваше нещо от сорта на "Redraw window content on resize" или нещо такова.
Засега не съм видял подобен аналог за X, но ако някой знае нещо по въпроса, нека сподели - и аз съм заинтригуван...

Ако говориш за движение на мишката и си забелязал забавена реакция - ти я мръдваш, а тя се чуди малко накъде да тръгне - в никакъв случай това не е поради X протокола, защото мишката се управлява изцяло от X-сървъра; не е нужна комуникация с клиента, за да бъде изрисувана на новата й позиция. Наистина, клиента се уведомява и може да смени формата й, ако иска, но не той я движи или рисува, така че X протокола не може да забави движението й.

За клавиатурата е още по-странно. Наистина не виждам как протоколи, които в случай на X клиент и сървър на една машина на практика просто местят данни в паметта и правят минимална обработка могат да са толкова бавни, че да ги видиш с просто око. Колкото и превключвания към / от ядрото да се случват и колкото и да е overhead-а на тези протоколи, клавиатурата праща по няколко байта за натиснат клавиш ... ако и това бави X, не виждам как изобщо може да се изрисува нещо, примерно да гледаш филм

Направи си прост опит - две програмки, които комуникират през Unix сокети. Примерно, правят ping - едната е клиент, другата сървър. Клиентът взима текущото време, записва го в пакет и го праща на сървъра, който го връща; клиентът след това вижда колко време е минало. Функциите getitimer и setitimer ще ти свършат работа; работят с точност микросекунди.

Съгласен съм с абсолютно всичко което си написал. Какво е Pro/ENGINEER? Вече мисля , че причината се корени не в wm а в gui библиотеката.