|
|
|
Бъдещи подобрения в X-а на FreeDesktop
|
|
|
|
|
|
от Огнян Кулев(5-11-2003)
След като на всички стана ясно, че добрият стар XFree86 не ще да се развива, вече има и конкретни насоки за подобрение, които може и да не бъдат в официалния свободен X сървър. Те са предложени от Havoc Pennington, добре известен в тези среди. Накратко, става въпрос за следното:
- X сървърът да държи копие на съдържанието на прозорците. Досега всяко пречертаване изискваше приложението да прерисува всичко. Всеки, използвал X, вижда това, даже и нищо да не разбира от архитектурата на X. Ще отнема известно количество памет, но и без друго скоро 32 бита (4G памет) за нищо няма да стигат.
- Освен window manager, вече ще има и composite manager, който ще стои между копието на прозореца и реално показваното изображение на екрана и ще може да прави трансформации. Конкретно, това е алфа преливането между прозорци. Друга употреба е в програми като VNC, които съвсем просто ще хващат образа на екрана. Трето приложение е OpenGL (3D) трансформации, както ще може и задаващия се Longhorn.
Друг известен участник в X-а на freedesktop.org е Keith Packard, създателят на Xft, или както сега е по-известно: FontConfig. Тъй че този клонинг на X едва ли ще загине, каквато съдба може би очаква Xouvert, който, според един коментар в OSNews, няма нито един доказал се разбирач от X фронта.
<< Blender 3D версия 2.30 | Novell купува SuSE за $210М >>
|
|
|
|
|
Хъмм... От: Димитър Жеков <jimmy__at__is-vn__dot__bg> На: 5-11-2003@7:33 GMT+2 Оценка: 1/НеутраленЗа #1 - то и сега си има backing store, поне в XFree86. За #2 - аман с тия прозрачни прозорци, а OpenGL в прозорец си има открай време (даже и в Win9x), друг е въпроса, че почти няма драйвери, които да го поддържат. И въобще, при толкоз трески за в X-а, точно с тия ли глупости намериха да се занимават...
[Отговори на този коментар]
Към: Хъмм... От: Огнян Кулев <ogi< at >fmi[ точка ]uni-sofia[ точка ]bg> На: 5-11-2003@7:54 GMT+2 Оценка: 1/НеутраленОтносно #1:
"Backing store is usually a decelerator"
-- Mark Vojkovich, http://xfree86.desiato.de/xfree86/pipermail/xpert/2001-December/013621.html
(В други писма се оплакват, че на всичкото отгоре е бъгав и неподдържан.)
Относно #2:
Не "OpenGL в прозорец", а "Всеки прозорец може да се трансформира чрез OpenGL (от composite manager) без програмата въобще да се усети".
Редактиран на: 5-11-2003@7:57
[Отговори на този коментар]
Към: Към: Хъмм... От: al_shopov На: 5-11-2003@9:31 GMT+2 Оценка: 1/НеутраленНе е задължително смесването по алфа канал да се прави чрез OpenGL. Може да се ползва Render. И той върши подобна работа. Проблемът с OpenGL е, че всичко трябва да се извърши в един основен прозорец, което не винаги е възможно.
Хубавото на OpenGL е, че често е хардуерно ускорен за разлика от Render, но в момента драйверите малко по-малко започват да използват двумерно хардуерно ускорение (което е по-трудно да се постигне ;-D, защото при 3Д има стандарти - OpenGL и донякъде Direct3D, докато при 2Д е положението е много разнообразно. Пак в скоби - това е проблем и за Майкрософт - не могат да накарат доставчиците на карти да си напишат добре ускорени двумерни драйвери, което и обяснява донякъде преминаването към 3Д за 2Д операции)
Другата хубост, която обаче не виждам отрязена в новината е, че всички тези предложения са от страната на X сървъра и се вместват прекрасно в текущата архитектура на X, като ще позволят още по-добро използване на мрежовата лента между клиента и сървъра.
Това разширяване ще позволи бързо местене на прозорци, смесване между прозорци и шантави ефекти на минимизиране и максимизиране както в Mac OS X. Евентуално би могло да се използва и за мащабиране на прозорци подобно на Winamp 3 и 5. (не съм сигурен за мащабирането, но ми се струва съвсем възможно).
Тези нововъведения нама да решат проблемите при преорамеряването на прозорците - в момента то често е на стъпки и има забавяне ако се използва преоразмеряване с показване на съдържанието на прозореца.
Това трябва да се разреши чрез добра координация между мениджъра на прозорци и комплекта графични обекти - например GTK Или QT.
Да отбележа също - xft и fontconfig не са едно и също. Xft е набор от API-та за изобразяване на шрифтове от страна на клиентската програма. Той зависи конкретно от X. Fontconfig е система за откриване и избиране на шрифт и попълване на кодирания. Системата е платформено независима - може да се нагоди и към Windows или да се вгради в принтер.
А и да не забравя - изискването към паметта не е толкова страшно ;-). Паметта, която ще се използва е тази на видеокартата (ако тя не стига - се преминава към основната памет). Това е чуден начин да се оползотворят купищата мегабайти, които идват с всяка видеокарта и които се използват реално единствено и само за съхраняването на текстури за игрички и до този момент бяха почти безполезни за всичко останало.
Голям фен съм на X. И как да не съм - направен е 1985г. и е толкова гъвкав, че все още се вмества в първоначалната рамка и може да се поддържа съвместимост.
Хип хип ура и да живее мрежовата прозрачност, Пакард и Пенингтън.
[Отговори на този коментар] Към: Към: Към: Хъмм... От: Огнян Кулев <ogi (a) fmi__dot__uni-sofia__dot__bg> На: 5-11-2003@9:59 GMT+2 Оценка: 1/НеутраленСамо леко пояснение към това, което Шопов каза. Не става дума трансформациите винаги да минават през OpenGL. Composite manager-а, който като window manager-ите е потребителска програма, си решава през OpenGL ли ще го прекарва, или през RENDER възможностите на драйвера, или каквото си иска друго.
Ъ-ъ, и като каза, че си фен на X-а, чел ли си 7-ма глава на Unix-haters handbook[1][2]? Вярно, че е от преди 10 години, но архитектурата си е принципно същата.
[1] http://www.molgen.mpg.de/~wwwutz/Unix_Haters/x-windows.html
[2] http://reactor-core.org/unix-haters-handbook.txt (пълен текст)
Редактиран на: 5-11-2003@10:03
[Отговори на този коментар] Към: Към: Хъмм... От: Димитър Жеков <jimmy< at >is-vn__dot__bg> На: 5-11-2003@13:06 GMT+2 Оценка: 1/Неутрален"Backing store is usually a decelerator" (В други писма се оплакват, че на всичкото отгоре е бъгав и неподдържан.)
Така де, но оправянето на bs още не е причина да се напише цял нов X сървър. Могат просто да го оправят в xf86. А аз съм по принцип за bs, като си помисля как ми стои видеопаметта незползвана и вместо това ми се товари процесора. И под win~1 е същото.
[Отговори на този коментар] Към: Към: Към: Хъмм... От: Огнян Кулев <ogi__at__fmi[ точка ]uni-sofia[ точка ]bg> На: 6-11-2003@7:52 GMT+2 Оценка: 1/НеутраленНе е нов сървър, а развиване на сегашния. Пък и тази работа с composite manager-а звучи достатъчно яко, за да се прави :-)
[Отговори на този коментар]
Да не объркваме нещата От: al_shopov На: 5-11-2003@23:44 GMT+2 Оценка: 1/Неутрален1. По отношение на смесване чрез OpenGL - OpenGL НЕ позволява да вземете два прозореца и хоп да ги смесите по канал, дори и да ги представите като текстури. За да ползвате OpenGL ви трябва контекст за изобразяване - в него се описват много неща - като се почне от тримерни обекти, осветление, начин на проекция и т.н. Двумерното използване на OpenGL се получава като се опрости ситуацията и контекста. Най-общо, за да имате такъв контекст - трябва да си го направите и да си го гледкате през един или повече прозорци. За да ги смесвате всички прозорци трябва най-долният прозорец (root-а) както и всички останали да бъдат в общ контекст или самият X сървър да изобразява чрез OpenGL. Това не е невъзможно за съвременните карти на PC-тата и Macintosh-ите обаче е непрактично за всички видове дисплеи (а Х требе да върви на всичко - и на ютията даже).
2. За пренаписването на сървъра - няма такова нещо. Това което Packard направи е собствен клон за разработка на Х сървъра (това е частта, която отговаря за интерпретацията на X протокола) - без драйвери, модули, шрифтове и т.н. понеже Packard няма CVS достъп до официалния XFree86 пък и се изпокара с доста от разработчиците (всъщност част от тях решиха да се изпокарат с него). Не е страшна ситуацията - той си предоставя разработките обратно за merge-ване. Ама е хубаво да ръчка разработчиците да отварят процеса на разработка.
3. Доколкото разбирам - това което в момента присъства в XFree86 и се нарича backing store не отговаря по възможности на нововъведенията. Целта на текущия backing store е да намали визуалните артефакти при преоразмеряване и показване на поне частично закрит прозорец, както и намаляване на изискванията към честотната лента. Освен това - напълно възможно е да се нашише драйвер, който ама въобше да не поддържа backing store, защото има ситуации, в които не може да си позволим разхищение на памет - например във вградени устройства. Текущия backing store си е нещо съвсем стандартно и присъства в стандарта за X протокола - не е разширение. Не е задължително един прозорец да има backing store. За повече инфо - http://ftp.xfree86.org/pub/XFree86/4.2.0/doc/proto.TXT
Нововъведението е да се поддържа задължително чрез разширение копие на всеки прозорец и може да се обработва в сървъра. Т.е. не само случая да местим и показваме прозореца, а да го правим полупрозрачен, да си го анимираме, слагаме сянка и т.н. Радост за окото и голям труд за тези, които трябва да направят нещо, което да е полезно ;-) Тия работи ще се управялват от т.н. composing manager (който може да е и мениджъра на прозорци). Клиентите могат да управляват composing manager-а чрез сатндартни заявки на X протокола.
Ето един типичен пример където backing store не е достатъчен - полупрозрачните терминали. При тях всъщност няма полупрозрачност - терминалът си прихваща root прозореца сам, тегли картинката по мрежата, смесва я я с цвят я с някоя простотия и пак я тъпче обратно по мрежата - ужас. Сега това смесване ще се прави от X сървъра и няма разни картинки да хвърчат по мрежата. Като си местим терминалчето и картинката отзад ще се променя веднага, а не на стъпки и със забавяне.
Ясно е, че това не измества backing store механизма, но го прави излишен при наличието на достатъчно памет.
Системата е напълно съвместима с текущото положение - ако няма мениджър за композиране - пак си правим стекчета с прозорци които са напълно непрозрачни. Като странична забележка - в момента може да се правят пълна прозрачност на част от прозорец чрез разширението XShape (създадено от Packard) или ползването на overlay (това е екзотика).
4. Чел съм Unix Haters Handbook особено в частта за X. Ама хич не съм съгласен, че положоението е също толкова зле колкото едно време. Да зпочнем с това, че големите критики са от Завински, пък той е основния хакер за Х скрийнсейвърите. Второ - има ама една абсолютна нагла лъжа, че Х бил лош щото нямал стандартен комплект графични обекти. Истината е, че всички графични системи обвързани с графични обекти умряха за по-малко от 10 години. И тук включвам както Windows 3.h по това време и Mac OS Classic (а да не говорим, че и Longhorn напълно ще замени текущите линии на Windows 9x и NT). Какъв ужас щеше да е да сме обвързани с Motif (или Athena)- пфу. Хакерите зад Х са казали - не знаем как да правим графични обекти и затова нека всеки да си прави каквото иска, а не да затормозяваме света с нашите простотии.
UHH е най-полезна днес като напомняне, че Unix не е бил най-добрата система и не е идеален (по платоновси). Това което го отличава е, че може да бъде подобряван и има надежда за него (за разлика от други системи)
UHH днес е много далече от реалните проблеми.
Да не говорим, че често авторите са Unix хакери, които критикуват и с чувство за хумор. Много се надявам Майкрософт да избачкат една Linux Haters Handbook и да почнем да дебъгваме, дебъгваме и т.н.
ал_шопов
[Отговори на този коментар]
|
|
|
|
|
|
|
|