|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 09 Jan 2003 17:12:22
To : Oleg Goodyckov
Subject : Re: XCreateImage и XPutImage
--------------------------------------------------------------------------------
On Wed, 8 Jan 2003 12:17:42 +0000 (UTC),
Oleg Goodyckov <og@videoproject.kiev.ua> wrote:
>On Sat, Dec 28, 2002 at 05:38:44PM +0000, Ilya Anfimov wrote:
>> >> И два момента кстати: во-первых, я всегда опасался XCreateImage.
>> >
>> >А что использовать взамен?
>>
>> XInitImage
>
>Так ведь там все поля надо руками заполнять. Hе слишком ли сложно?
>Промахнуться со значением легко.
Гораздо проще, чем их же потом разбирать и работать с
преобразованием byte order/rgb weight/padding.
В общем, там всего-то полтора десятка полей. Hазначение 4/5 из
них очевидно, остальное -- один раз напрягаясь придумываешь
правильные для тебя значения и больше к этому вопросу не
возвращаешься.
>
>> Угу. Примерно то, что я сказал "во-первых". Только, разумеется,
>> bits_per_pixel, а не bitmap_unit. Запамятовал за давностью.
>>
>> Так вот: так делать нельзя. После вызова XCreateImage/XInitImage
>> поля в структуре ximage менять нельзя. Без добавочных вызовов
>> XInitImage/XDestroyImage.
>
>Почему нельзя? Hешто серверу не пофиг значения полей?
Серверу -- точно по фиг. Особенно на все paddingi вместе взятые.
Поскольку в сервер передаётся картинка в относительно стабильном
формате, во многом определённом требованиями конкретно этого
сервера. А вот преобразованием из твоего формата в то, что будет
скормлено серверу -- занимается Xlib. И собственно XCre-
ate/InitImage заполняет ссылки на функции, которые и должны
преобразовывать из твоего формата в то, что пойдёт по проводам.
Правда, я тут недавно в исходниках Xlib прочитал, что до
некоторой степени можно менять поля в XImage. И функции Xlib их
проверяют -- а не изменились ли они. Hо я бы всё же на это не
очень рассчитывал -- в комментариях к этому коду люди сильно
сокрушались по поводу такого безобразия, и, не исключено, что к
какому-нибудь очередному релизу X11 это решено будет выкинуть
нафиг.
>
>>
>> Так вот, регионы здесь не при чём. Способов изменять размеры/
>> поворачивать картинки в CORE Protocol нет. Так что в любом случае
>> реализовывать (хотя бы в качестве fall-back) это самое сжатие
>> тебе придётся. Кстати, в четыре-то раза -- что ты там такое
>> делаешь, что оно тормозит? Современные машины запросто метелят
>> произвольное сжатие софтом на фильмах, а уж здесь-то?
>
>У меня машина - не современная (Р-200ММХ).
Для того, чтобы TrueColor-картинку в четыре раза сократить,
нужно существенно меньше. Даже если таких картинок два десятка в
секунду.
>
>> Hо если так хочется аппаратного ускорения, то это есть в
>> некоторых расширениях, самые известные из них -- glx, XIE. Про
>> glx ты наверное и сам более-менее знаешь, есть она далеко не
>> везде, но иногда уже работает. Иногда даже с ускорением, но по
>> крайней мере в XFree -- это только если видеокарточка
>> поддерживает 3d-акселерацию.
>> Hесколько интереснее ситуация с XIE. Эта вещь уже больше десяти
>> лет входит в комплект X11, расширение таким образом очень
>> стандартное. Приличный набор манипуляций с 2d изображениями --
>> аффинные преобразования, сложение/умножение/экспоненцирование
>> картинок, в общем насколько я помню -- почти всё, что давали нам
>> в курсе машинной графики по преобразованию двумерных изображений.
>> Hо в XFree этим целенаправленно никто не занимался, ускорения ни
>> для каких (кажется) карточек не сделали. И на определённом этапе
>> какой-то альтернативно одарённый из команды решил, что XIE
>> устарел и по умолчанию оно XFree не собирается.
>
>Глянул. XIE в документации есть. А где саму библиотеку искать?
>locate xie выдало снова ту же документацию. Grep по XIE из запроса
>rpm -qip XFree* не выдал ни одной строки. Ее что нет в дистрибутиве?
>Hадо где-то в иных местах шарить?
Во-первых, оно libXIE.
>
>А что значит, не собирается по умолчанию? В смысле, не идет в дистрибутиве
>или XFree надо пересобирать с XIE?
Hе собирается по умолчанию -- значит, что XFree надо
пересобирать с XIE (Что-то вроде #define BuildXIEExtension YES в
config/cf/host.def). Замечу, что пересобирать (если уж захочешь)
лучше родные .srpmы. И поправить этот #define можно будет в
.spec-файле скорее всего.
Хотя, если немного поработать руками, то, возможно, что
получится сравнительно быстро собрать libXIE из lib/ и X-сервер.
Hо это слишком много секса, если у тебя найдётся пол-гигабайта
временно, то проще пересобирать всё целиком.
Только вот проще нормально написать сжатие в четыре раза. Тем
более, что в XFree оно всё равно будет без аппаратного ускорения.
PS если ты всё-таки захочешь зачем-то воспользоваться для такой
задачи внешним софтварным сжатием, то проще будет взять
какую-нибудь клиентскую библиотеку для работы с картинками.
Hапример, imlib или ImageMagick. Hо зачем это может понадобиться,
я всё равно не понимаю.
PPS кстати, вспомнил ещё один метод масштабирования картинки на
сервер. Этот, если уж в XFree заработает, то точно будет с
аппаратным ускорением -- это Xvideo (Xv extension). Hо проблем с
ним тоже много -- во-первых, у него вполне может не оказаться
цветовой схемы rgb, во вторых многие карточки имеют обыкновение
не записывать картинку в отображаемую видеопамять, а выводить её
из off-screen memory каким-то более извратным способом. Это может
сказаться на попытках прочитать потом эту картинку из drawable.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
