Положение дел в мире графики для Линукса

>Похоже всех очень тронули слова этого человека...
мне кажеться из этого что то выйдет...

Дык поэтому так рьяно и взялись за перевод. Слава небесам, нашёлся хоть кто-то, кто, главное правильно, расшифровал, что происходит.
Теперь людям будет яснее, куда :) двигаться далее.

По переводу: сейчас размещу как есть, потом, конечно, пройдусь по тексту, расположив рядом три окошка: одно с оригиналом и два с тем, что мы напереводили.

всё сразу не берёт, посчу частями...

-------------------- Будущее направление

Линух возможно будет не последним главным десктопом имплементирующим десктопный ГУЙ способный выжрать всю мощу GPU. Считая что какой-либо гонки больше нет, возможно долгосрочное решение приемлимо. Мы могли бы спроектировать новый сервер основанный на OpenGL или Cairo.

Вообще целая концепция программируемого граф железа не адресуется в апи подобных xlib и Cairo. Это очень важный момент. Одна из главных новых фич GPU, программируемость просто не доступна из современных апи. OpenGL демонстрирует эту фичу посредством языка шейдеров.

Рассматривая новый сервер убедитесь что концептуальный дизайн расщеплен на два компонента: платформо-зависимую и независимую. Драйвера устройств платформо-зависимы, в предложенной модели OpenGL рассматривается драйвером устройства и будет иметь платформо-зависимую реализацию. Все вопросы интеграции с другими подсистемами линуха будут спрятаны внутри соответствующих драйверов. Главный сервер будет реализован с использованием кросс-платформенных апи подобно сокетам, OpenGL и EGL. Кросс-платформенное апи для устройств допускающих горячую замену будет необходимо указать. Сервер не должен проектироваться с нуля. Существенные часи кода могут быть натырены из других проектов и должны быть скомбинированы новыми способами. Из того что я могу увидеть 95 или более процентов кода необходимого серверу уже существует.

Модульность это ключ к созданию хорошего сервера. Дизайн последнего должен быть разделён на изолированные библиотеки взаимодействующие посредством стандартных интерфейсов. Такой способ делает лёгким замену библиотеки. Вы можете иметь полностью различные реализации библиотеки на различных платформах или возможна куча способов реализации этой библиотеки на одной платформе. Конечно кросс-платформный код имеет свои преимущества. Вещи подобные библиотеке Mesa могут разделяться всеми целевыми системами.

Помните как DirectFB использует безрутовый X? Новый сервер должен запускать безрутовый X с софтверным рендерингом для достижения традиционной (?) совместимости. Модель прямого рендеринга DRI это хорошее дизайнерское решение, которое надо использовать в будущих серверах. Движение (?) X в традиционный режим позволяет иметь полную свободу в новом дизайне сервера.

Например, новый сервер может иметь новый сетевой протокол. Недавняя статья в Linux Journal об "No Machine" и "NX протоколе" показывает что X протокол может быть ужат в соотношении 200:1 и больше. Новый протокол должен быть основан на OpenGL и спроектирован так чтобы избежать задержек типа "поездка туда-обратно" (переводчик: видимо имеется ввиду общение X-клиент<->X-сервер) и обеспечивать долговременное кеширование изображений. Chromium интересная система поддерживающая OpenGL дисплей расщепляемый на несколько мониторов соединённых сетью. Их сетевая библиотека отслеживает состояние OpenGL (переводчик: имеется ввиду OpenGL представляемая как finite state machine, то бишь с точки зрения разработчика, реализующего OpenGL апи) что является одним из способов уменьшения сетевого трафика.

Кеш глифов также должен быть проанализирован. В текущем X сервере клиент создаёт битмапы глифов и посылает их серверу где они кешируются. Эта модель препятствующая генерированию глифов посредством GPU описана в вышеупомянутой статье. Шрифты на стороне клиента это хорошая идея. Приложение определённо должно отвечать за layout (переводчик: хорошего русского аналога этого термина не знаю). Но не существует настоящего требования для создания битмапов глифов на стороне клиента. В случае масштабируемых шрифтов генерируемых посредством GPU необходимо передавать больше данных нежели простой битмап на сторону сервера.

Новый сервер мог бы адресовать текущие недостатки в сетевом звуке и печати. Он мог бы поддерживать соответствующую ретрансляцию (proxying) необходимую чтобы перекреплять (reattach) сессии. Он определённо должен быть с самого начала спроектирован для поддержки многопользовательности (переводчик: видимо имеется ввиду захват некоторых устройств первым пользователем при нескольких сессиях на одной консоли).

Обработка событий это хороший пример реализации посредством библиотек. Линух имеет evdev, kernel hotplug, HAL и D-BUS. Эти подсистемы не существуют на большинстве других платформ. Поэтому подсистема ввода для BSD должна выглядеть сильно отличной от спроектированной для линуха. Делая главные подсистемы модульными мы можем приспосабливать их и полностью использовать окружение на котором они запускаются. Это подход отличный от выделения общей части этих окружений.

X используется разными развед службами в мире. Текущий X сервер известен тем что недостаточно безопасен для использования с важными документами. Если бы нужно была сделать основная работа по проектированию то это надо было бы сделать с нуля с безопасностью в уме. Некоторое соответствующее субсидирование должно должно пройти длинные пути для гарантии что правильные фичи имплементированы.

Если в двух словах, то есть много вещей которые надо сделать и недавняя разработка начата чтобы адресовать эти вопросы. Вопрос номер один это менеджер памяти для DRM и переработка необходимая для FBO (framebuffer objects - фреймбуферные объекты) в драйверах DRI. Вопрос номер два это зачистка (переводчик: :-) ) драйверов fbdev соответствующих железу для которого есть драйверы DRM. С фундаментальной работой в этом месте работа над новым проектом сервера могла бы быть начата.

Вот пара абзацев... больше лень. :) VGA Legacy Оригинальная архитектура IBM PC подразумевает существование ограниченного перечня устройств, в соответвие каждому из которых ставятся широко известные адреса; к примеру доступ к порту COM1 осуществляется по адресу 0x3F8. К сожалению, поддержка VGA большинством видеокарт реализуется по тому же принципу. Пока в системе имеется лишь одно устройство графического вывода, VGA не представляет проблемы. Вставьте вторую видеокарту - и оба устройства будут пытаться занять один и тот же адрес на шине. Текущая реализация Х-сервера содержит код, позволяющий использовать более одного VGA-адаптера. Однако при этом другие пользователи не получат доступа к графическому устройству. Блокирование таких пользователей (программ) - не лучшее решение, поэтому необходимо найти способ управления доступом пользователей к VGA-устройствам. Лучшее решение, которое можно реализовать под Линукс, - добавить Механизм VGA-Арбитража (VGA arbitration mechanism) в ядро. BenH работает над тем вариантом, что недавно обсуждался в OLS.

grob и анонимус зачёт :) . Всегда сможете в 2007 сказать, что-то вроде этого:
"-ааа, та самая статья, что лежит на всех серверах инета... да, да, как же, знаком..., вот тот и тот абзацы я и переводил..."

Теперь мой убогий перевод начала, как-то и не смотрится :) . Я и сам думал попереводить - не успел :) . Муторное это вообще дело текст добавлять... У grob/a и svu вот мало ошибок на единицу объёма текста, примерно 1 на всю часть. У некоторых больше :).

Всё же, там неточностей ещё много.

> фрейм => кадр, frames per sec. == кадров/с

several seconds a frame (так в оригинале) и frames per sec -- сильно разные вещи, по крайней мере, с точки зрения грамматики. :) Они, скажем так, обратные.:) Готов согласиться на "сек. на кадр."

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

Если еще что осталось переводить, и не очень много спец. железячной лексики -- я рвусь в бой! :)

> grob и анонимус зачёт :) . Всегда сможете в 2007 сказать, что-то вроде этого: "-ааа, та самая статья, что лежит на всех серверах инета... да, да, как же, знаком..., вот тот и тот абзацы я и переводил..."

мы тут не один, и мне зачёт уже не нужен :)

> Теперь мой убогий перевод начала, как-то и не смотрится :) . Я и сам думал попереводить - не успел :) . Муторное это вообще дело текст добавлять... У grob/a и svu вот мало ошибок на единицу объёма текста, примерно 1 на всю часть. У некоторых больше :).

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

> Всё же, там неточностей ещё много.

да в оригинале и автор не блещет оборотами...

2 domenick (01.09.2005 23:08:35)

Ой, спасибо Вам за координацию работы по переводу интереснейшей концептуальной статьи, которую Вы организовали! Признаться, в силу не очень свободного владения английским, перевод, в некоторых случаях, помог мне более правильно осознать кое-какие нюансы... :-)

2 All

Спасибо всем участникам данного треда, принявшим участие в сём благом деле! Надеюсь, к моменту необходимости "шлифовки" текста ваш пыл не увянет... Удачи! И... почаще бы так, делово! :-)

Не корневой режим а режим супер пользователя :)

И Вам спасибо. Я всегда говорил - вместе мы сила :).

Нам бы вот только так же собраться, давно бы записали "ось", которую вообще бы уже никогда никто не догнал :) . Для этого надо только, чтобы мы выдвигали пожелания, а Джон Смирл сразу же всё это воплощал в коде :).

X Window servers come in both rooted and rootless versions. On a dedicated hardware graphics terminal, X is what it does. On a personal computer, X is merely one of many capabilities. The terms rooted and rootless only have meaning in the context of a computer. A rooted X server commandeers the entire screen, mimicking a dedicated hardware X terminal. A rootless one shares the screen with other applications and the underlying operating system's desktop.

-- http://www.macwrite.com/criticalmass/x-on-mac-os-x-part-3.php

rooted и rootless - это зависит не от привилегий пользователя, который запускает сервер, а от того, управляет ли X всем экраном (грубо говоря) или нет.

Вобщем желательно продолжать корректировать текст теперь более вдумчиво.

Постараюсь учесть лучшее с вики варианта в варианте на www.teleology.ru, так чтобы в итоге пришли к одному.

Давайте определимся "Х сервер" или "Х-сервер" по тексту в целом.
Я за Х сервер, так, как Х-сервер хоть и давнее, но, насколько я знаю, как раз некорректно составленное в прошлом название.

Я категорически :) за Линукс, а не за Linux, раз уж это перевод - конечно, здесь речь не о том, чтобы писать рут, а не root, например.

"Чип" и "микросхема" я старался использовать соответственно контексту. Если хотите, давайте прикинем и всё закатаем либо в чип, либо в микросхему.

domenick, ты забыл мои пару абзацев. Хоть и немного, но жаль, если пропадет. :)

VGA Legacy

The original design of the IBM PC had a somewhat limited set of peripherals located at fixed, well known addresses, for example COM1 at 0x3F8. Unfortunately, the VGA support on most graphics cards is one of those legacy devices located at a fixed address. As long as you only have one graphics card in your system, VGA is not a problem. Plug in a second one and now you have two pieces of hardware both wanting to occupy the same bus address.

The current X server has code to deal with multiple VGA adapters. But this X server code is unaware of other users of these devices and it will stomp all over them. Stomping on these other programs is not nice, so we need some way to coordinate multiple users of the VGA device. On Linux the best solution for this is to add a VGA arbitration mechanism to the kernel. BenH has been working on one that was discussed at OLS.

==

Наследие VGA

Оригинальная архитектура IBM PC подразумевает существование ограниченного перечня устройств, в соответвие каждому из которых ставятся широко известные адреса; к примеру доступ к порту COM1 осуществляется по адресу 0x3F8. К сожалению, поддержка VGA большинством видеокарт реализуется по тому же принципу. Пока в системе имеется лишь одно устройство графического вывода, VGA не представляет проблемы. Вставьте вторую видеокарту - и оба устройства будут пытаться занять один и тот же адрес на шине.

Текущая реализация Х-сервера содержит код, позволяющий использовать более одного VGA-адаптера. Однако при этом другие пользователи не получат доступа к графическому устройству. Блокирование таких пользователей (программ) - не лучшее решение, поэтому необходимо найти способ управления доступом пользователей к VGA-устройствам. Лучшее решение, которое можно реализовать под Линукс, - добавить Механизм VGA-Арбитража (VGA arbitration mechanism) в ядро. BenH работает над тем вариантом, что недавно обсуждался в OLS.

Я б даже сказал ... тяжелое наследие. :)

беру Splitting console

2 domenick (02.09.2005 0:36:34)

>Нам бы вот только так же собраться, давно бы записали "ось", которую вообще бы уже никогда никто не догнал :) . Для этого надо только, чтобы мы выдвигали пожелания, а Джон Смирл сразу же всё это воплощал в коде :).

:-)) А почему именно Джон? :-))

В качестве шлифовки перевода. В абзаце "Устаревающее аппаратное обеспечение" я предложил бы Вам заменить фразу "Никакое количество программирования не превратит VGA карту в ATI X850" на "Никакое качество программирования не превратит VGA карту в ATI X850" или "Никакой качественный программный код не превратит VGA карту в ATI X850". Для себя я воспринал это именно так. И в общем контексте абзаца, по-моему, это больше соответствует мысли автора... Хотя дословно - далеко не факт...

Да простит меня уважаемый Socrat_ (01.09.2005 13:57:25)...

:-)

> Кстати, неплохо бы у автора спросить об условиях публикации перевода.
> Например, выкладывание текста в википедии наверняка нарушает авторские права.

Jon Smirl
August 30, 2005
Permission is granted to freely translate and republish.

>заменить фразу "Никакое количество программирования не превратит VGA карту в ATI X850" на "Никакое качество программирования не превратит VGA карту в ATI X850" или "Никакой качественный программный код не превратит VGA карту в ATI X850".

Гы! А еще правильнее - "Одним программированием ни за что не превратить VGA карту в ATI X850".

:) Не забыл. Я злопамятный :) . Вобще-то ужинал или что-то вроде этого :) .

Сейчас придётся разделить на три части. Что не делается - всё к лучшему :). Так что слегка притормозится.

Надо там всё окультуривать начинать - пока выглядит тяжело..., кстати, да... эххх... Тяжёлое наследие ВГА..., а ведь только-только ЕГА был в радость... после ЦГА-то, того, который после, когда :) на телевизор, нда... (смахнул скупую слезу) :).

2 anonymous (02.09.2005 1:52:40)

> "Одним программированием ни за что не превратить VGA карту в ATI X850"

И с этим вариантом согласен... Во всяком случае, тож соответствует общему контексту... ;-)

>:-)) А почему именно Джон? :-))

Предлагайте варианты..., страна должна знать своих героев.

По корректировакам, тут много накопилось. Надо это всё как-то утрясать начинать. Я соориентировался в начале на Вику, но там как-то не то и не быстро. Пока буду выбирать варианты, как мне больше нравится. Потом скажите, как исправить.

И вообще, имейте совесть!!! Я ещё сам статью не читал... :)))

2 domenick (02.09.2005 2:03:06)

> после ЦГА-то, того, который после, когда :) на телевизор, нда... (смахнул скупую слезу) :)

Ага... А мне сейчас уж и "скупую" слезу очки смахнуть мешаютЬ... :-)))

... "Никаким количеством выпитого пива не превратить лягушку в принцессу" :)

Чо сделать-то осталось? А то может подсоблю, пока пиво перед сном пью :)

> "Одним программированием ни за что не превратить VGA карту в ATI X850"

> "Никакое качество программирования не превратит VGA карту в ATI X850"

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

Вобще всё понятно, конечно, но "Никакое качество программирования" слегка режет слух... :) Может быть так:

"Нет такого программирования, чтобы превратить VGA карту в ATI X850",
"Каким бы то ни было программированием не превратить и так далее...".
Не знаю. Что выберем?

Теперь необходимо количество перевода переводить в качество. Всё выглядит совсем не так, как я думал тихо мирно перевести :).

Вобщем можешь неспеша, отхлёбывая пиво :) , двигаться по переведённым частям (последовательно :) ) и дотошно комментировать, что тебе не нравится в переводе. На мой взгляд, задача, как раз для тебя и, возможно, по силам :). Только неспеша, чтобы я править успевал.

domenick, я тебе по почте переслал перевод Drawing the line, здесь почему-то оставить не получилось.

Ок. Но я бы не исключал вариант про принцессу, говоря про лягушку и VGA :)

Небольшой перерыв - у меня второй ужин... Или ночной обед... :) не знаю.

> Splitting console

Раздваивая консоль

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

Возможно разделить код консоли в зависимости от выполняемых функций - и разрешить множество существующих проблем. В первую очередь, системная консоль должна быть абсолютно надежной, в любых обстоятельствах. Она не должна быть быстрой. Ее код должен быть максимально простым - и он должен работать во время обработки прерывания, во время паники ядра. Подразумевается использование для восстановления системы, в однопользовательском режиме. Очевидно, нужно отображать загрузочные сообщения, поддерживать систему отладки ядра kdbg. Эта консоль предоставляет SAK и экран безопасного входа в систему. Для поддержки нескольких пользователей, входящих через разные мониторы, присоединенные к одному видеоадаптеру, консоль должна работать независимо на каждом мониторе. Одним из способов доступа к консоли было бы нажатие клавиши SysReq, консоль бы перекрывала текущее изображение и использовала текущий видео-режим. Отладчик ядра от Novell работает именно так. Системная консоль не поддерживает виртуальных терминалов и не переключаема. Т.к. она использует текущий видео-режим, она может работать даже в случае экстренных обстоятельств, например, отображая фатальные ошибки ядра.

Дизайн системной консоли использует fbdev для ослеживания режима и нахождения скан-буфера. Для обеспечения максимальной надежности всякое ускорение вывода отключено. Fbconsole использует системный CPU для прямых манипуляций с видео-буфером. Вывод консоли отображается путем прямой записи в видео-буфер, используя поддержку растровых шрифтов в fbconsole.

Пользовательская консоль работает совсем по-другому. Она должна быть быстрой и дружественной к пользователю. Работа вне ядра облегчает поддержку многопользовательского режима - путем создания отдельного процесса для каждого пользователя. Режим пользователя упрощает использование аппаратного ускорения, предоставляемого GPU через fbdev и DRM. Кроме того, доступны Xft/FreeType для полной поддержки Unicode. Правильный дизайн консоли сделает возможным работу разных пользователей с разными подключенными видео-мониторами. Используя разные клавиатурные комбинации, можно имитировать поведение, аналогичное существующим виртуальным терминалам и поддерживать переключение консолей. Т.к. нынешние консоли выполняют все функции, при переключении виртуальных терминалов пользователь работает с обоими типами. В новой модели клавиши переключения виртуальных терминалов дают консоли, работающие в пользовательском режиме. SysReq вызывает системную консоль. Командный интерпретатор, работающий в системной консоли, может быть высокоприоритетным процессом - для облегчения перехвата управления у "проблемных" процессов.

Угумс... Отлично. Только, я всё ещё не со своей основной машины. Постараюсь вспомнить :) пароль к почте и через веб интерфейс попробую забрать.


Перевод разделил на три части. Начал нумеровать главы в соответствии с Викой.

Вступление я скорректировал вполне на моём сайте. То что на Вике не здорово, на мой взгляд. Предлагаю к вступлению более не возвращатся.

Давайте корректировать теперь 1. История.

(Сохраните промежуточный результат, на всякий случай, пока корректируем).

Моя цель -- сделать наиболее подходящий литературный перевод, максимально близкий к тексту. Я буквоед :)

"После завершения работы над Xgl я получил множество email писем" -> "После прекращения работы над Xgl я получил множество писем по электронной почте". "электронная почта" -- хоть и не столь лаконичный, как "email", но устоявшийся русский термин. "Я написал эту статью, чтобы объяснить, как все части стыкуются(складываются) друг с другом". Гм. Продолжая про Athena мне может стать плохо от стиля... Мой вариант: "Родившись в 1984 из проекта Athena, он хорошо служил сообществу UNIX все эти годы".

"Использование X широко распространено" -- (c) translate.ru? Хотите верьте, хотите нет, но некоторые особи мужского пола используют свой "Х" каждый день. Так что нужна другая формулировка. К сожалению, тут близко к тексту не получится. Мой вариант: "X-server используется повсеместно на рабочих столах пользователей Linux." Долго думал как сказать "тот, кто делает всё" одним словом, не придумал.

"Wikipedia статья раскрывает гораздо больше деталей, но упомяну лишь о двух преимущественных X новшествах с открытым кодом, что позволили кросс-платформенную поддержку и сетевую прозрачность" -- ребята! translate.ru наш старший брат что ли?! "<a href ="">Статья</a> рассказывает о многих деталях, но две самые главные их них, это открытость исходного кода, которая позволила получить переносимость между платформами, и сетевая прозрачность.".

так, пора постануть.

2 domenick (02.09.2005 2:03:06)

> No amount of programming is going to turn a VGA card into an ATI X850

:-)) У меня, после прочтения Вашего поста... Тож... Нда... :-))) Очухался... ;-)

Рискну предложить ещё один вариант (см. выше) "Никакое программирование не сможет", и далее по тексту.

2 Casus (02.09.2005 2:17:14)

И то!!! В данном случае и Ваш вариант очень даж ничо! Но излишне образно и далече от... ;-)

PS. За сим прощаюсь на восемь часов. Объявили посадку... Прилечу - первым делом в этот топик и... Сами знаете, на какой сайт. :-)

Снова отлично. Только вот это сразу: > Splitting console

Раздваивая консоль.

Так, конечно, конкретнее, но хмм... может быть
останемся с прежним: Разделяя консоль. или: Разделение консоли. ?

Drawing the line.

Comments, suggestions etc are appreciated.

As is, blah-blah-blah.

нРПХЯНБЙЮ КХМХХ

оН ЩРНЛС ОНБНДС ДН ЯХУ ОНП ХДСР ДХЯЙСЯЯХХ. б кХМСЙЯЕ, Б ДЕИЯРБХРЕКЭМНЯРХ, ЕЯРЭ РНКЭЙН НДХМ ЯОЯНЯНА ПЕЮКХГНБЮРЭ ДЕЯЙРНО Я ЮООЮПЮРМШЛ СЯЙНПЕМХЕЛ ЦПЮТХЙХ МЮ НЯМНБЕ НРЙПШРНЦН ЙНДЮ √ ЩРН Mesa OpenGL. пЮГСЛЕЕРЯЪ, ЛНФМН АШКН АШ ЯНГДЮРЭ ЙКНМ DirectX, МН ЙРН, ЯОПЮЬХБЮЕРЯЪ, АСДЕР ОХЯЮРЭ БЕЯЭ ЩРНР ЙНД Х ЯННРБЕРЯРБСЧЫХЕ ДПЮИБЕПЮ? OpenGL МЕ РЮЙНИ СФ ОКНУНИ БЮПХЮМР. нМ НАЪГЮРЕКЭМН ОПХЯСРЯРБСЕР Б КЧАНИ ЯХЯРЕЛЕ. нМ ЯРЮМДЮПРХГНБЮМ Х ЩРНР ЯРЮМДЮПР ЙНМРПНКХПСЕРЯЪ ARB (??ЮЯЯНЖХЮЖХЪ ЙНМРПНКЪ ЮПУХРЕЙРСП??). нМ ДНЯРЮРНВМН ПЮГПЮАНРЮМ Х МЕОКНУН ДНЙСЛЕМРХПНБЮМ. нМ ЬХПНЙН ПЮЯОПНЯРПЮМЕМ Х РЮЙ ФЕ ЬХПНЙН ОПХЛЕМЪЕРЯЪ. б ЙНККЕДФЮУ НМ БУНДХР Б ОПНЦПЮЛЛС НАСВЕМХЪ Х Н МЕЛ МЮОХЯЮМН ЛМНЦН КХРЕПЮРСПШ. лМНЦХЕ ГЮЛЕВЮРЕКЭМШЕ ОПХКНФЕМХЪ (Б РНЛ ВХЯКЕ ХЦПШ) ЕЦН ХЯОНКЭГСЧР. мЮ ЙЮЙНЛ ФЕ СПНБМЕ ДПЮИБЕП БХДЕНЙЮПРШ ДНКФЕМ НРПХЯНБШБЮРЭ КХМХЧ? XAA Х fbdev ДЕКЮЧР ЩРН МЮ МХГЙНЛ СПНБМЕ. хУ API ХЛЕЧР ДЕКН РНКЭЙН Я РНВЙЮЛХ (ОХЙЯЕКЪЛХ) Б ТПЕИЛАСТЕПЕ, bitblit, Х ЛНФЕР АШРЭ, ЯНАЯРБЕММН, КХМХЪЛХ. бЯЕ ОПНВХЕ БНГЛНФМНЯРХ, ОПЕДНЯРЮБКЪЕЛШЕ БХДЕНВХОНЛ (ЛХЙПНЯУЕЛНИ?), МЮ ЩРНЛ СПНБМЕ МЕДНЯРСОМШ, КХАН ДКЪ ХУ ПЕЮКХГЮЖХХ МСФМШ ДНОНКМХРЕКЭМШЕ API, ЯОЕЖХТХВЕЯЙХЕ ДКЪ ЙНМЙПЕРМНЦН ВХОЮ. б ЯКСВЮЕ Xgl НРПХЯНБЙЮ ОПНХЯУНДХР ЯНБЕПЬЕММН ДПСЦХЛ ЯОНЯНАНЛ. кХМХЪ НРПХЯНБШБЮЕРЯЪ ВСРЭ КХ МЕ МЮ ЯЮЛНЛ БШЯНЙНЛ СПНБМЕ Я ХЯОНКЭГНБЮМХЕЛ МЕОНЯПЕДЯРБЕММН OpenGL API. ъ ЯВХРЮЧ, ВРН РЮЙНИ ОНДУНД АНКЕЕ ОПЮБХКЭМШЛ. кХМХЧ ФЕКЮРЕКЭМН НРПХЯНБШБЮРЭ МЮ ГМЮВХРЕКЭМН АНКЕЕ БШЯНЙНЛ СПНБМЕ, ВЕЛ РНР, ВРН ГЮЬХР ЯНАЯРБЕММН Б ВХО, ВРНАШ ЩРХ ОПНЬХБЙХ ЛНЦКХ ДЮКЭЬЕ ПЮГБХБЮРЭЯЪ, МЕ ГЮРПЮЦХБЮЪ БШЯНЙНСПНБМЕБШЕ API. лМЕ ЙЮФЕРЯЪ, кХМСЙЯ МЕ БШХЦПЮЕР НР РНЦН, ВРН ЕЛС ОПХДЕРЯЪ ХЛЕРЭ ДЕКН Я ЖЕКНИ ЯЕПХЕИ(???) API, ЙЮЙ Б ЯКСВЮЕ Я DirectX. аНКЕЕ ОЕПЯОЕЙРХБМШИ ОСРЭ, МЮВЮБ Я ЯЮЛНЦН БШЯНЙНЦН СПНБМЪ, Х НАЕЯОЕВХБ ЯННРБЕРЯРБСЧЫСЧ ОПНЦПЮЛЛМСЧ ОНДДЕПФЙС (Mesa), ГЮРЕЛ ГЮЛЕМЪРЭ ВЮЯРХ ЩРНИ ОПНЦПЮЛЛМНИ ОНДДЕПФЙХ МЮ ЮООЮПЮРМСЧ (DRI).

дЮКЕЕ, ДКЪ OpenGL ЯСЫЕЯРБСЧР ПЮГКХВМШЕ ПЕЮКХГЮЖХХ: Mesa, Nvidia Х ATI. йЮЙСЧ ХУ МХУ БШ ХЯОНКЭГСЕРЕ, ЩРН БЮЬЕ КХВМНЕ ДЕКН, УНРХРЕ БЕПЭРЕ, УНРХРЕ МЕР, МН МЕЙНРНПШЕ ОПЕДОНВХРЮЧР ЙНЛЛЕПВЕЯЙХЕ ДПЮИБЕПЮ. Xgl ГЮДСЛШБЮКЯЪ ЙЮЙ ОЕПЕУНДМШИ БЮПХЮМР МЮ АКХФЮИЬЕЕ АСДСЫЕЕ. еЦН ЖЕКЭ ГЮЙКЧВЮКЮЯЭ Б РНЛ, ВРНАШ ОПНГПЮВМШЛ НАПЮГНЛ ГЮЛЕМХРЭ ЯХЯРЕЛС НРПХЯНБЙХ Б ЯСЫЕЯРБСЧЫЕЛ X-ЯЕПБЕПЕ МЮ ЯНБЛЕЯРХЛСЧ, НЯМНБЮММСЧ МЮ OpenGL. бЯЕ у-API Б Xgl ЯНУПЮМЕМШ ЙЮЙ ОЕПБХВМШЕ, МХЙЮЙХУ МНБШУ ББЕДЕМН МЕ АШКН, Х МХЙЮЙХЕ МЕ АШКХ НАЗЪБКЕМШ СЯРЮПЕБЬХЛХ. Xgl √ ЩРН БШЯНЙНСПНБМЕБШИ, ЙПНЯЯ-ОКЮРТНПЛЕММШИ ЬЮАКНМ (code base), ЙНРНПШИ МСФМН ОНПРХПНБЮРЭ ДКЪ ЙНМЙПЕРМНИ ПЕЮКХГЮЖХХ OpenGL. нДХМ ХГ РЮЙХУ ОНПРНБ, Xglx, ОПЕДМЮГМЮВЕМ ДКЪ GLX API. дПСЦНИ, Xegl, ПЮАНРЮЕР Я ЙПНЯЯ-ОНКЮРТНПЛЕММШЛ API EGL. яКЕДСЕР ГЮЛЕРХРЭ, ВРН EGL √ ЩРН ОКЮРТНПЛЕММН-МЕГЮБХЯХЛШИ ЯОНЯНА ДКЪ ЯНГДЮМХЪ GLX, AGL Х WGL API. оНЯКЕ ДНАЮБКЕМХЪ Mesa ЙЮЙ ПЮЯЬХПЕМХЪ, EGL ЛНФЕР СОПЮБКЪРЭ МХГЙНСПНБМЕБШЛ ТПЕИЛАСТЕПНЛ. рЮЙНЦН ЯНВЕРЮМХЪ ДНЯРЮРНВМН ДКЪ РНЦН, ВРНАШ ЯНГДЮРЭ НЙНММСЧ ЯХЯРЕЛС (РХОЮ ЯСЫЕЯРБСЧЫЕИ Б МШМЕЬМЕЛ X ЯЕПБЕПЕ) МЮ ОПНЯРНЛ ФЕКЕГЕ. мН Xgl √ РНКЭЙН БПЕЛЕММНЕ ОЕПЕУНДМНЕ ПЕЬЕМХЕ, Х ЙНЯРШКЭ ОН ХЛЕМХ EXA, ОНГБНКЪЪ НРРЪМСРЭ ЯПНЙ ЕЦН БМЕДПЕМХЪ, ОПЮЙРХВЕЯЙХ ДЕКЮЕР ЕЦН ОНЪБКЕМХЕ СФЕ МЕНАЪГЮРЕКЭМШЛ. оЕПХНДХВЕЯЙХ БЯОКШБЮЧЫХИ ДНБНД ГЮЙКЧВЮЕРЯЪ Б РНЛ, ВРН ХЯОНКЭГНБЮРЭ OpenGL БННАЫЕ МЕ ЯРНХР. б МЮЬЕЛ ПЮГБХБЮЧЫЕЛЯЪ ЛХПЕ ЯКХЬЙНЛ ЛМНЦН СЯРЮПЕБЬЕЦН ФЕКЕГЮ. дКЪ ЩРНИ ОПНАКЕЛШ ЕЯРЭ ДБЮ ПЕЬЕМХЪ. оЕПБНЕ, OpenGL ЪБКЪЕРЯЪ ЛЮЯЬРЮАХПСЕЛШЛ API. хЯОНКЭГСЪ ОПНЦПЮЛЛМСЧ ЩЛСКЪЖХЧ (software fallbacks) ЕЦН ЛНФМН ХЯОНКЭГНБЮРЭ МЮ НАНПСДНБЮМХХ КЧАНЦН СПНБМЪ. OpenGL ES РЮЙ ФЕ НАЕЯОЕВХБЮЕР БНГЛНФМНЯРЭ ОПНТХКХПНБЮМХЪ API. оПНТХКХ ОПЕДЯРЮБКЪЧР ЯНАНИ ВЕРЙН НОПЕДЕКЕММШЕ ОНДПЮГДЕКШ OpenGL API. еЯКХ ОНМЮДНАХРЯЪ, ЛШ ЯЛНФЕЛ БШДЕКХРЭ ОПНТХКЭ, ЯНДЕПФЮЫХИ ЛХМХЛЮКЭМШИ МЮАНП OpenGL API. пЮГЛЕП ЙНДЮ МЕ ОПНАКЕЛЮ, ДНЯРСОМЮ ОПНОПХЕРЮПМЮЪ ПЕЮКХГЮЖХЪ OpenGL ES ПЮГЛЕПНЛ 100йb. еЫЕ НДХМ ОННТХКЭ OpenGL ES МЕ РПЕАСЕР ОНДДЕПФЙХ ОКБЮЧЫЕИ ГЮОЪРНИ. мХВРН МЕ ЛНФЕР БНЯОПЕОЪРЯРБНБЮРЭ ОНЪБКЕМХЧНРЙПШРШУ ПЕЬЕМХИ, ЕЯКХ РНКЭЙН МЮИДСРЯЪ ЯННРБЕРЯБСЧЫХЕ ПЕЯСПЯШ. дПСЦНЕ ПЕЬЕМХЕ √ ОПНЯРН-МЮОПНЯРН ГЮОСЯЙЮРЭ МЮ ДЮММНЛ ФЕКЕГЕ РНКЭЙН РЕ ОПХКНФЕМХЪ, ЙНРНПШЕ ДКЪ МЕЦН ОПЕДМЮГМЮВЕМШ. аЕЯОНКЕГМН ФДЮРЭ, ВРН Windows Longhorn АСДЕР ПЮАНРЮРЭ МЮ IBM PC, МН МЮ РНИ ФЕ PC АЕГ ОПНАКЕЛ ПЮАНРЮЕР DOS. йКЧВЕБНИ ЛНЛЕМР √ РН, ВРН OpenGL АНКЕЕ ЛЮЯЬРЮАХПСЕЛ, ВЕЛ EXA. пЮЯЬХПЪЕЛНЯРЭ EXA ХЛЕЕР СЪГБХЛНЯРЭ МЮ ЯЮЛНЛ БШЯНЙНЛ СПНБМЕ √ НМЮ МЕ ОНЙПШБЮЕР БЯЕ ПЮЯЬХПЕММШЕ БНГЛНФМНЯРХ ЦПЮТХВЕЯЙНЦН ОПНЖЕЯЯНПЮ, РЮЙХЕ ЙЮЙ РПЕУЛЕПМЮЪ ЦПЮТХЙЮ Х ОЕПЕОПНЦПЮЛЛХПСЕЛНЯРЭ (programmability). оПХ ХЯОНКЭГНБЮМХХ OpenGL ЛШ ЛНФЕЛ ХЯОНКЭГНБЮРЭ НДХМ Х РНР ФЕ API ДКЪ ЛНАХКЭМНЦН РЕКЕТНМЮ Х ДКЪ ЯСОЕПЙНЛОЭЧРЕПЮ.

Вы что-то сказали?

Отлично. Я почему-то в тебя верил с самого начала :).

Возвращаемся к вступлению. После размещения подробно скорректирую вступление, соответственно твоему сообщению.

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

Нда, вот с Рисованием линий не всё гладко в Датском королевстве.

Спасибо и за терпение также - я оценил несколько попыток передать сообщение. Постараемся порадовать Вас размещением перевода.

"Тем не менее прошло двадцать лет со времени разработки X, за которые изменилось видео оборудование." -- это просто: "Прошло уже 20 лет со времени разработки X-server, и с тех пор оборудование очень сильно изменилось."

"Если вы посмотрите на схему современной видео микросхемы, вы обнаружите небольшой блок, называемый 2D" -- друзья! товарищи! математики! переводчики, в конце концов! Давайте будем расшифровывать термин типа "2D". "...небольшой блок, ответственный за "плоскую"/двумерную графику". Тогда про "3D" мы можем сказать "объёмная графика".

"десктоп" -> "рабочий стол". устоявшийся термин.

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

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

Ух... какой корявый абзац, если честно...

Вот Casus, что ты сказал подправлю и пойду смотреть другой Х сервер, может хоть у Морфея с драйверами всё не так плохо.

До завтра, друзья мои. :) "Пейте чай с шиповником, он очень полезен, в нём много витаминов (с)".

Но вообще замечания твои очень дельные. Благодарствую. Сам понимаешь, кроме тебя пока литературной коррекцией перевода никто особо не занимался.

Отбой теперь.

... я подумал и решил добить абзац до конца, и пойти спать. Итак, со слов "Теперь производители" до конца азаца надо выкинуть всё. Вот мой вариант, поскольку мы уже говорили "в былые времена", то теперь скажем: "в настоящий момент (2005г)". "В настоящий момент производители графических микросхем скрывают всю информациб об их микросхемах, затрудняя для держателей патентов поиск нарушений патентов. Точнее, производители говорят эту легенду, что это причина для сокрытия информации о программировании микросхем. Так же они говорят, что сокрытие информации о микросхемах затрудняет конкурентам понимание как именно работает их микросхема, но в этом я сомневаюсь так же, как и в легенде про патенты. Всё эта скрытность делает задачу написания драйвера с открытым исходным кодом для этих микросхем очень трудной. Вместо этого, нас заставляют полагаться на производителя, что он предоставит свои драйвера для своего новейшего (самого нового?) оборудованя. В случае, если вы ещё не заметили, производители графических микросхем заботяться только о MS Windows, так что они делают минимально возможное для поддержки своего оборудования в Linux. Есть исключения. Intel предоставляет драйвера с открытым исходным кодом для некоторых своих микросхем. Nvidia/ATI предоставляют свои собственные драйвера, но они отстают от версий для Windows. В результате, мы имеем очень разную по качеству смесь драйверов, от очень хороших до никаких.

Всё, пиво допито, меня нет. "информациб об их микросхемах" -- звучит коряво, лучше "их" убрать.

Ммать, куда ни гляну в переводах, охота ссаными тряпками кидаться. Кто там "безопасность и корень" переводил? Ядро Linux (не советую писать "линукс") содержит около 10 миллионов строк кода _исполняемых_ (было: запускаемых) с привилегиями суперпользователя (было: из под root). Ну и так далее. Пора спать. А то уже трезвею.

Шит. "19. Эффективность кооперации." -- я помню русское такое слово "кооператив". Но "Эффективность взаимодействия" куда как более понятна и по-русски.

Это я не заметил или оно только недавно появилось:

"Permission is granted to freely translate and republish." ?

Это в конце оригинальной статьи. :-)