>> А это тем кому формочек не хватило и/или захотелось эффектов.
> Такие, как показывает практика, идут стоем на ЙУХ.

Это они в вашей локальной резервации идут на йух. А в моей например - я люблю симпатичные программы. И не только я.

> Всё равно, сделать компоненты красивее, чем у E17/16 не получится. А выглядеть
> будет не в пример топорнее и неудобнее.

Не вижу ничего такого особого в E16/17. Ну виджеты. Обычные. Под кути и gtk есть и более симпатичные мне темы и менее. Если учесть что полезного мне софта на этих тулкитах не обнаружено, я его просто игнорирую.

> Крайне сомнительно. Почему браузеры и флеш так безбожно тормозят с видео? Скорее
> просто их бэкенды под Х сделаны через попу.

...потому что идеальная с точки зрения апликушника графическая подсистема должна требовать к себе минимум внимания. А вот это не про иксы с их тоннами костылей и подпорок.

> Ну нельзя же в одной бобочке 20 лет ходить. Ясен пень, что нужно рисовалку развивать.
> Но говорить, что не надо носить фуфайку из-за того, что она пачкается и портится!

Ну вообще-то вы тут вроде ратовали за унифицированный вид контролов с таким нахрапом, и тут же признаете что да фиг с ним - нехай будет разнобой. Ну раз такая пьянка - пусть клиент и рендерит в своих либах. Выглядеть для юзера будет однофигственно. Зато не надо переписывать либы на которых весь популярный софт и пыжиться с разгребанием потенциально ломовой нагрузки на сервер если он сложным рендерингом займется, с антиалиасингом и прочим рендерингом векторных фонтов.

> Кроме того, вы не учитываете, что введение новых компонент сперва в офис,
> а потом в Винды - это давняя традиция MS. Я бы даже сказал, монополистическое жлобство.

Офисы сроду юзают какие-то кастом-контролы которые остальным в результате в лапы вообще толком не дают. MS с удовольствием забивает на свои дизайн-гайды, наглядно показывая что это только для чернорабочих. А им, первому сорту, можно на свои же гайды с удовольствием забить. Да и вообще, свое как известно не пахнет, а доходить это начинает только когда как с IE - он теперь в рунете на 4-м месте ажно. Вот тут начинается паника и рытье окопов от забора до обеда с пониманием того что надо конкурировать, правда с непривычки совсем не понятно как это делать. Ведь делать юзеру удобно за столько лет напрочь отвыкли. А юзеры честно срулили на более удобные программы. Вот как-то так кой-кто и порастерял свое могущество в вебе...

>> разных процессов, в том числе и достаточно быстрых, работы с графикой,
>> видео, эффектами и чем там еще.
> Больше 60 ФПС человеку не нужно.

Вообще, нынче иногда хорошо бы и 120. Для стерео-картинок. Но даже и 60FPS на приличных разрешениях сплюнуть в иксы стандартными методами через их обычный протокол будет проблемой. Нет, есть всякие костыли и расширения, только они где-то сбоку и зачастую опциональны и реализованы не везде. Что очень доставляет апликушникам.

>> прозрачность в том виде как это делают иксы - нужна полутора землекопам.
> Не сказал бы. Сейчас много клиент-серверных программ внутри предприятий, на локальной сети.

Я думаю что клиент-серверных применений использующих именно иксовый протокол нынче не густо. А у всех остальных оно как-то устраивает а без понтов и наворотов в виде одинаковых окошек там и тут они уж как-нибудь перекантуются. Им это не главное.

> Часто делают на браузерах, хотя проще сделать через Х. Всё-таки, С++
> значительно приятнее JavaScript'a. Да и быстрее.

Да, и самое издевательское - это когда яваскрипт в браузере рисующий в канвас или активно меняющий существенные части страницы начинает клинить севый код в иксах. Данная ситуация выглядит особенно тупо. Скрипт может жрать чуть ли не меньше иксов, радостно упершихся в полку на своем ядре. Во зашибись!

>> А как насчет осциллограмму снятую микроконтроллером на usb с приличным
>> FPS показать? Ну так, первое что в бошку взбрело.
> На 100 мегабитной сети легко.

Да блин, хотя-бы локально. 60 FPS в нормальном разрешении? Если это делать через иксовый протокол - иксы раком встанут. По поводу чего придется сильно усложнить себе жизнь узнав о всяких расширениях где-то сбоку. А при желании еще и другим прогу раздать - можно узнать много интересного о том что вон то и се - опционально, эти драйвера на вон то кладут, в общем попадос на написание чего-то типа мплеера, с кучей подпорок. Удивительно ли что в свете такой опы все дружно юзают opengl по возможности? Он как раз мимо всего этого дурацкого протокола летит и куда резвее. Но почему кто-то должен юзать нечто ориентированное на профессиональных игроделов и тому подобные мощные 3D аппы чтобы даже простую картинку быстро выводить - я не понимаю. Это явный оверкилл.

> Я же работаю по такой сети с Математикой.

А я с ней не работаю. И еще дохрена пользовтелей - тоже.

> Именно работаю, а не мучаюсь. При этом легко работает Animate,
> перестраивает графики как на локальной машине. И это даже на извращении
> Xming, не только на Xorg'е.

Как бы перестроение графиков - одно, а допустим осциллограмма с того что на входе с нормальным FPS и постоянно - уже чуть другое и предъявит уже поболее требований. И тиринг сразу нехорощим словом вспомним, и производительность будет интересовать и прочая.

> В локалке сетевая прозрачность Х со всем, кроме видео, работает.

Да, потому что видео надо нормальную производительность графической подсистемы а не тот шЫт который могут предложить иксы в дефолтовом виде без костылей с своим суперкрутым протоколом. Хотя по логике вещей, очень многим пользователям было бы удобнее если б видео нормально игралось без всяких расширений, а как там будет с сетевой прозрачностью - дело десятое. Вот в вэйланде эти приоритеты и переставили по другому. Я ж говорил что вам не понравится. Да, это менее академично и более приземленно. Маргиналам с очень кастомными затеями оно менее удобно и может создать больше проблем. Потому и ругаются :)

> Просто многие хотят и через Интернет. А когда оно, увы, обламывается, говорят "так
> не доставайся же ты никому!". И ратуют за выпиливание сетевой прозрачности.

Во первых - да, если уж делать фичу, она должна нормально работать. Во вторых, это все-таки не настолько популярная фича. Во всяком случае есть достаточно пользователей которые ей не пользуются никогда. Поэтому ставить ее во главу угла концепции в ущерб остальному, более приземленному - достаточно спорная затея.

>> Ну это мы будем посмотреть. По-моему они отлично понимают то что делают.
> Тогда бы они не орали, что хотят десктоп, а там client-side-decorations. Вот
> это - чистой воды маразм!

В этом мире никого не интересует степень маразматичности решения если оно работает и делает свое дело. Те кто делает вэйланд нацелились на простую мишень: сделать просто, шустро и с минимальной переделкой существующего софта. Софт уже работает как работает. Переделывать его и лежащие под ним либы - отдельный сказочный геморрой. Ибо пишется все это другими. Половина с удовольствием покажет вам и вашему концепту средний палец или покрутит пальцем у виска. На чем все и закончится. Ну вот перцы и нацелились на реалистичный и достижимый goal который можно достичь за разумное время, сделав лучше чем было с минимальными усилиями (ИЧСХ достигли чего-то работающего уже, в отличие от X12 и прочих концептуальных инициатив, которые бы потребовали намного больше времени и ресурсов). Да, ценой ряда tradeoff-ов. Не самых вкусных и нравящихся не всем. Зато реальный результат который может быть кому-то полезен за реалистичное время. "Лучше синица в руках чем журавль в небе".

>> Как по мне так трублешутить тормоза 1 программы проще чем system-wide
>> компонента и проблем меньше.
> Да ничего не будет. Сейчас же cairo не тормозит. А так она даже не будет
> делать трапеизацию всего и всея.

Не тормозит если с ней ничего не делать. А если анимацию на 60FPS с размером близким к размеру экрана дуть или там гору текста рендерить оптом - вот это уже совсем не факт.

>> Это у вас он 300х300 пикселов, а у меня 800х480.
> Ну нельзя же так смешить, право слово! Я на меньше, чем на
> 1920хЧто-то стараюсь не работать. А как появятся retina по гуманной цене,
> сразу же перейду на них.

У этого который 800х480 есть один убойный плюс, за которое многое можно простить: я могу его унести на край Земли на своем горбу не чертыхаясь. И энергией его могу неделю обеспечивать без розеток. А 1920хчтототам это круто, но с ним например невозможно свалить на природу отдыхать, etc. Поэтому я не против оных и за. Но считаю это не единственным сценарием. Я считаю что мне нужны системы разных калибров. И большие и маленькие.

>> Зато стало клинить мышь и вообще графику при
>> нагрузке на систему. Ноги вытащили - хвост увяз. Я что-то не
>> хочу себе систему с такими же свойствами.
> Ну тут ядро Linux с его планировщиком и nice подкачало.

Это вообще-то о винде было :). Я не знаю как MS сломал то что до эторго работало, но - факт. В семерке и висте там курсор клинит злее чем на старых пингвинах. Чудеса индусской инженерии. Более того - в последних версиях линукса и графического стека эта проблема как-то сильно ослабла. Я ее на себе вообще не ощущаю. Зато попав в семерку - громко ругаюсь, ибо клинит мышь.

> Увы, не Haiku. :-( Нужно выставлять приоритет прорисовщику чуть выше,
> чем обычному процессу, и всё будет ок.

Особенно ок все будет если внести туда фич потяжелее и потом рендерануть пару метров текста векторными фонтами с антиалисингом и всеми наворотами без какого либо лимитирования программ в том что они могут делать. Вот когда вообще всех остальных начнут тормозить в пользу рендеринга текста - видимо и будет ок. Но мне такая система будет искренне несимпатична. Я не лю когда у меня клинит мышь и дергается графика.

> Впрочем, планировщик Windows - это вообще патентованное гoвно - он начинает лагать,
> когда процессов становится больше, чем ядер. Поэтому может быть на Linux
> всё и обойдётся и так.

Вы вообще меня неправильно прочли. И предъявили линуксу, хотя это было про винду. И да, я помню - раньше такая проблема была, анноило. Сейчас она как-то сильно ослабла и по крайней мере мышь катается нормально в большинстве случаев. Может, заслуга в развитии всяких там KMS/DRM и прочих в последнее время? Хотя это лишь предположение.

> Их и сейчас столько же, просто рисовалка внутри тулкита. А у меня даже более UNIXвейно. :-)

Да уж, и более академично. Концепт стройнее, но на практике вероятнее всего был бы полным абзацем из-за неидеальности мира, как обычно. Ну и того что пользователи математики по сети обычно страшно далеки от народа и его нужд :)

>> Вообще, я могу наблюдать тенденцию что вэйлэнд будет дружить с иксами.
> Иначе он вообще будет слит в унитаз. Он же не поддерживает без
> них ни одного коммерческого приложения под Linux. Не поддерживает ни одной
> графопостроительной программы.

Узкоспециализированные графопостроительные программы нужны очень небольшому проценту пользователей. По поводу чего слит в унитаз конечто будет, но 0.1% пользователей, например. По поводу чего никто ничего и не заметит особо. Ну то-есть, 0.1% будет недоволен, зато 99.9% смогут юзать графическую систему без тормозов. И их довольство системой существенно возрастет. Выигрыш перевешивает проигрыщ. С точки зрения системостроителей ориентированных на набор и удержание пользователей а не создание суперкрутой архитектуры и правильных концепций. А поскольку программисты тоже люди и иногда могут захотеть посмотреть фильм, поиграть в игру, попользоваться браузером с современными фичами без тормозов и не хуже чем в других ОС, или хотя-бы просто захотеть написать программу выводит уйму графики в какой-то контрол в реалтайме. Будь оно анализатор спектра, осциллограф, показометр или что там еще, где желательна быстрая перерисовка существенной области, в том числе и битмаповой но совсем не желательно таскать с собой столько костылей и подпорок сколько это делают "полновесные плееры видео".

>> Да, однако это не значит что времена выполнения запросов программ поделятся нормально.
>> По крайней мере если не городить ужас с персональым процессом-спутником или
>> крутой арбитр ресурсов.
> Почему? Зачем арбит? Рисовалка отдаёт битмап композеру - это быстро, а когда
> рисует - долгий процесс, её сторожит ОС. Поэтому достаточно именно разделения
> "композер"-{"рисовалка"-"тулкит+программа"}.

Проблема в том что распределение ресурсов рендерера между программами никак не контролируется. Выдавать каждой программе по персональному рендереру - выглядит довольно расточительно по ресурсам, особенно если рендерер сложный и жирный. А если это какой-то общий компонент, да еще способный к деланию тяжелой работы - всегда есть шанс что некая программа вгрузит в него вгрузит изрядно работы. И пока он ее будет жевать - "и пусть весь мир подождет". А вот пользователю не понравится что остальные программы курят бамбук пока некая особо умная программа усиленно рендерит 20 метров текста векторными фонтами. В этом плане то как оно сейчас - далеко не самый плохой вариант. В том плане что никаких лишних процессов, шаред либы тулкитов в 1 копии в памяти и копируются только отличия, а попытка отрендерить 20 метров текста векторным фонтом на скорость - клинит исключительно самого виновника торжества. Ну и пусть себе висит наздоровье. Чертыхнемся и переключимся в другого. А вот если это вызовет общесистемные проблемы и тормоза - это уже плохо.

> Почему жирно? Это же форк - код разделяемый, общие данные типа шрифтов
> тоже разделяемы, а данные программы - свои.

И тем не менее, как показывает пример апача, и старт форка занимает вполне себе некое время, и ресурсов оно вполне себе кушает. В общем мне в системе не нужен "апач от графической системы", уж извините.

> Самый, что ни на есть UNIX-way: mingetty, getty, login, сервера, все так поступают.

Есть очень умная поговорка: все хорошо в меру. Вот и форки - тоже. Срач в системе процессами-спутниками на каждый процесс - это явный оверкилл. Ну то-есть вы конечно можете пользоваться такими дизайнами если вы считаете это правильно, а я как-нибудь пешком постою и поюзаю нечто с более вменяемым дизайном. Любую идею можно довести до абсурда. Даже форки. Вот форк процесса-спутника на каждый процесс - это оно самое.

>> Оно конечно да, но посмотрев на апач vs nginx я как-то за последнего.
> Я думаю, что там в другом проблема, не в fork.

В ряде случаев - и в нем тоже. И память оно умеет жрать прилично. В общем форк это хорошо. А вот злоупотребление оным - хреново и потенциально может вызывать проблемы.

> Те же console-helper и т.д. работают отлично.

Так на них и нагрузка не такая как на графическую систему и их немного. Форк ничем таким не плох, если его в меру. Но форкать процесс-спутник каждому процессу выводящему графику - явный перебор. Вот еще не хватало какому-то вшивому индикатору температуры проца в трее здоровый процесс-спутник раскочегаривать. Хвост виляет собакой!

>> Судя по тому что вы активно кивали на тормоза оконных менеджеров,
>> вы с такими программами просто дел не имеете вообще.
> Только с Mathematica/Matlab - всякие 3D графики.

Я не думаю что они сильно активно лупят перерисовку графиков в объеме который мог бы напрягать. А вот например хоть тот же спектроанализатор аудиоплеера или приблуда типа осциллографа - на стандартном иксовом протоколе будет очень не фонтан. Вот и получается что какой-то вшивый спектроанализатор должен стать чуть ли не mplayer-ом в плане вывода графики.

>> снимать. Оптимальнее взять примитивный ножик.
> Если резак у вас под рукой, а ножик нужно ковать и обтачивать, лучше взять резак.

Еще спорный вопрос что быстрее будет. Нормальный человек почертыхается и руками шкуру с апельсина отдерет. Маньяк будет неделю писать концептуальную программу очистки апельсина лазером, изведет мешок апельсинов для тестов и так далее. Несомненно, круто и технологично и вызывает отвал челюсти у любого увидевшего. Но в реальной жизни ценность такого решения около нуля. Ну нет у типового покупателя апельсина такого резака. А у тех у кого он есть - это далеко не самое эффективное применение данной машины.

>> (если оно умеет вычисления - это что угодно но только не
>> плеер уже) и прочие эффекты, являющиеся частью стандарта.
> Для анимации нужно менять Х, внося туда анимационные примитивы. По-видимому. Они,
> кстати, были.

Я бы даже сказал что не столько анимация, сколько "вычисляемая графика". Анимация - да, ее можно заранее вгрузить. Но для canvas, спектроанализаторов, осциллоскопов, показометров, ряда и прочая вгрузить анимацию заранее - не прокатит. Надо чтобы прсото быстро работал вывод графики.

> Так это проблемы тулкитопейсателей, а не прикладушников.

А они тоже хотят поддерживать кучу систем и им не резон сильно мучаться с особенностями каждой графической подсистемы.

> Мы только их и обсуждаем. А те прикладушники, которым нужен выход за рамки
> тулкитов должны, увы, тоже изучать графсистемы.

Вот хорошая граф.система должна работать, делать свое дело и требовать к себе абсолютный минимум внимания. Иначе ее будут всеми силами избегать и не будут на нее ничего портировать. Кто же хочет себе дофига геморроя на бошку? Особенно ради осчастливливания 0.1% юзерей с какими-то специфичными задачами.

>> на основе xine они зарекомендовали себя жутко глючными.
> А по мне - вполне надёжными.

Ну не знаю, мне с плеерами юзающими xine как-то не везло: они с грохотом валились на самых обычных файлах которые остальные играют. Сильно разбираться не стал и просто поюзал плееры которые этим не страдают, т.е. vlc и mplayer. Потому что у меня нет самоцели жрать конкретный сорт кактусов. Учтя что браузер заведомо имеет дело с внешними данными скроенными абы как (а потенциально еще и хакерские эксплойты бывают, где данные специально кривые) - меня как-то не устроит такая "надежность".

>> И да, а что насчет canvas и прочих эффектов?
> Тут, увы, придётся браузеростроителям либо остаться при своих, либо изучать граф. систему.

Ну вот они и сделали так как проще им. В ущерб пользователям иксов слегонца. У пользователей соответственно есть поводы не жаловать иксы. За отсутствие стандартных mandatory методов не выбивающихся за обычное апи потребных для быстрого вывода графики.

> Но я завёл разговор про видео в FF для того, чтобы намекнуть
> на некоторую невменяемость браузеростроителей.

Они как раз вполне вменяемы. Просто они пекутся об удобстве своих задниц и о том как с минимальными затратами ресурсов осчастливить побольше разных пользователей. А сильно рвать зад и лезть в дебри ради 0.1% всякой экзотики никто не будет. Будете настаивать - скажут что "unsupported" и досвидания.

> Вы, конечно, упираетесь, но рисовать свой убогий видеопроигрыватель,

У него есть ряд специальных требований, из-за которых использовать уже существующие плееры может оказаться даже более проблематично нежели написать мелкий, специализированный. И да, если что - я юзал плагины встраивающие мплеер или vlc в мозиллу. Для веба это скажем так, работает очень дубово и криво. Нативный браузерный плеер не в пример приятнее. И не выглядит как бельмо на глазу, и вебпаги могут своим видео рулить так как задумано авторами, и стиль контролов плеера можно под остальное оформление сайта подогнать. А упомянутое есть, пашет, но выглядит как чужеродный элемент страницы - FAIL.

> когда есть минимум 3 отличных, готовых для встраивания - это невменяемость.

Только если не учитывать их goals и специфичные требования к плееру.

> Поэтому кто знает, что они нагородили с canvas. Скорее всего, они просто
> под Х писать не умеют и не хотят. Слишком мала доля Х-ов. Поэтому и переход
> на W не поможет - его доля тоже невелика.

А от W и не требуется "помогать". Его дело - не мешать. То-есть если некто рисует в канвасе, дело графической подсистемы при этом всего лишь максимально быстро сплюнуть это на экран и не выпендриваться.

> Это значительно быстрее, чем писать самостоятельно проигрыватель.

С учетом специфичных требований и того что танк изначально не совсем похож на трактор - не факт, напильник потребуется изрядный.