>> поросячьего визга тупому но быстрому фреймбуферу + opengl.
> Большинство программ чертят формочки. На кой ляд им OpenGL?А это тем кому формочек не хватило и/или захотелось эффектов.
> Это исключительно потому, что браузер сделан через попу. Сделаете вы другую система,
> а браузер всё одно будет сделан через попу.
Root cause именно тормозные 2D операции в иксах. Остальное следствие. Ведь на других графических системах браузеры таким не страдают.
> Эта задача вполне решаема и с общесистемной рисовалкой. См. те же Винды.
Наверное именно поэтому MS в офисе юзает кастом контролы, придумали всякие winforms и прочие WTF^W WPF-ы. А еще рисовалка может в GDI программах применять тему или не применять. По факту такой бардак получается что линух где установлена синхронная тема GTK и Qt (или просто рендеринг qt через gtk) на фоне этого просто эталон одинакового вида программ получится запросто ;)
> Это для 3-х уродцев браузеров. А для огромного кол-ва GUIшных программ ничего,
> кроме удобного интерфейса рисования формочек не нужно.
А еще некоторым программам надо поболее. Компьютеры нынче используются для визуализации разных процессов, в том числе и достаточно быстрых, работы с графикой, видео, эффектами и чем там еще. Есть еще и игры наконец. Как бы программы с формочками - это прекрасно но их сетевая прозрачность в том виде как это делают иксы - нужна полутора землекопам. А как насчет осциллограмму снятую микроконтроллером на usb с приличным FPS показать? Ну так, первое что в бошку взбрело.
>> Парни пилящие вэйланд кажется это осознали и решили
>> не ссать против ветра а использовать ветер в свое благо.
> Мне кажется, вы им сильно льстите. W всё-таки пишут не приходя в сознание.
Ну это мы будем посмотреть. По-моему они отлично понимают то что делают. Да, вам и arisu это наверное не понравится.
> Там и так есть рисовалка. Предлагается её просто обновить. Не более. Откуда
> обновлять - да вот из Cairo.
Угу, представляю себе если такие навороты как в cairo в иксы засунуть. Как по мне так трублешутить тормоза 1 программы проще чем system-wide компонента и проблем меньше.
> И как вы собираетесь программу с мобильного телефона с экраном 300 на
> 300 транслировать в 24-х дюймовый дисплей с помощью битмапов?
Это у вас он 300х300 пикселов, а у меня 800х480. По поводу чего сие вполне прилично выглядит на мониторах, что растянутое что в окне.
> Вы же умрёте рассматривая крякозябры. А с отрисовкой на сервере всё будет очень прилично.
Да вот живой как-то пока и не особо понимаю потуг осчастливить меня черти-чем.
>> Да, однако вы предлагаете выносить тяжелые и длительные операции в сервер графики.
> Они и так вынесены во многих системах. В тех же Виндах, к примеру. И ничего, не умирают машины.
Как бы вам сказать то? Положить GDI и оставить систему без руля и без ветрил - национальный вид спорта тех кто знает что такое GDI :). Потом даже таскманагер прорисоваться не сможет, ну и все - готов котенок. Даже снять проблемную задачу нельзя. Наиболее очевидные грабли такого плана MS хоть немного подлатал где-то в районе висты или семерки, чтоли. Зато стало клинить мышь и вообще графику при нагрузке на систему. Ноги вытащили - хвост увяз. Я что-то не хочу себе систему с такими же свойствами.
> Ну вот как раз нарисовалась чудесная архитектура:
> Композитор (пусть даже и W) < X с рисовалкой <= команды от
> тулкита <- команды от аппликухи
Все бы ничего но прослоек многовато.
> Плюс добавить для битмапов проброс в композитор сразу. Связь <= можно сделать
> сетевой. :-) Либо, можно сделать связь <- сетевой. Но это уж слишком радикально.
Вообще, я могу наблюдать тенденцию что вэйлэнд будет дружить с иксами. Как минимум некое время - точно. Потому что небольшая но все-таки часть программ юзает именно иксовый протокол а не тулкиты и сразу всех жестко прокатывать на работу такого софта как-то не есть правильно.
>> т.к. вот что-что а дележ времени CPU в честных многозадачках делают на совесть.
> Ну так и тут поделится нормально, раз ОС нормальная.
Да, однако это не значит что времена выполнения запросов программ поделятся нормально. По крайней мере если не городить ужас с персональым процессом-спутником или крутой арбитр ресурсов.
> Да никто не сбрасывает этот приоритет. Хотя, вы также сможете и снизить
> приоритет рисовалки.
Это вариант только в случае изврата когда эта рисовалка обслуживает только 1 процесс (что больно жирно, пардон). Иначе это затронет иные процессы.
> Он уже взлетел при запуске оконного менеджера или первой Xовой программы. Он
> должен будет лишь форкнуться. То есть, у него должно быть максимум
> разделяемых данных и минимум своих. Ну есть же всякие CoW и т.д.
Оно конечно да, но посмотрев на апач vs nginx я как-то за последнего. А опач но из графической подсистемы мне почему-то тоже не хочется. Fork в юниксах конечно достаточно прикольный и эффективный вызов vs создание процесса с нуля, но это не значит что его надо везде тыкать по максимуму. "Когда у вас в руках молоток, все вокруг кажется гвоздями"? :)
>> уперлись программы - я видел, да.
> Я - нет.
На программах с формочками так не получится. Для этого надо программы с выводом графики все-таки. Судя по тому что вы активно кивали на тормоза оконных менеджеров, вы с такими программами просто дел не имеете вообще.
> духе NIH. Я категорически с вами несогласен, что MPlayer/xine/VLC все сделаны неудовлетворительно.
Они сделаны нормально. Просто неудобно как-то промышленным лазерным резаком шкуру с апельсина снимать. Оптимальнее взять примитивный ножик.
И да, опять же - вы упорно игнорируете неудобный вам топик - вычисляемая графика в canvas которую никакой плеер в принципе не осилит (если оно умеет вычисления - это что угодно но только не плеер уже) и прочие эффекты, являющиеся частью стандарта. А интересно, SVG рендерер тоже надо целиком в иксы втолкать? Вместе с его анимациями и прочая? А анимированные картинки - их тоже плееру? В общем ИМХО граф. система должна быть быстрой. Это снимает 100500 проблем 1 махом.
>> Три мануала и 100500 дополнений х 3 к каждому, etc, etc.
> ??? Ну если вы хотите писать программу под граф. систему, желательно что-то
> знать о граф. системе.
Если вы не заметили - обычно прикладники пишущие открытый софт как правило хотят юзать кроссплатформенный тулкит и не забивать себе бошку особенностями конкретных графических подсистем. Прибиваться гвоздями к 1 граф. системе - дурной тон. А самому все особенности каждой изучать во всех ОС коих дофига - упухнуть можно. Вот вы готовы изучить графические стеки всех ОС поддерживаемых GTK и Qt? За что-то такое их и юзают. И за это им и делегируют рендеринг кучи виджетов и прочая.
> Хорошо, отконфигурьте так, чтобы был лишь ваш формат, и всуньте в инсталлятор.
> Как-то sqlite всовываете, так почему libxine нельзя?
Скулайт изначально заточен на встраивание и добавляет лишь 300 кило кода со всми наворотами. И да, когда я в последний раз видел плееры на основе xine они зарекомендовали себя жутко глючными. И да, а что насчет canvas и прочих эффектов? А вот расскажите - есть допустим тест peacekeeper. В частности часть оного на скорость меняет элементы HTML, устраивая довольно красивый обсчитываемый эффект в стиле плазмоидов. Не понятно почему это должно давать паршивый FPS. И да, хочу посмотреть как вы ЭТО отдадите в libxine или какому там еще плееру. Если вы не поняли, в браузерах все идет к тому что это будет некая гибридная мультимедийно-документально-программная среда. Логичная точка конвергенции технологий.
> Там есть configure. Я же его компилял под Solaris/SPARC.
Там конечно есть, НО в нем настолько много всего лишнего что попытка впереть его в браузер будет напоминать советский анекдот про опиловку танка напильником до получения формы трактора.
