[devel] libjpeg7 - пора?

[Alexander Bokovoy]

Hi,

>> >> Редхат, руками Адама Ткаца, занялся jpeg-turbo.
>> > И даже уже принял решение перейти на нее в Fedora 14.
>> Да, правда соответствующая бага в редхатовской багзиле ужасает.
>
> Это какая? Я смотрел 600243.
Да, эта. Правда, это я там запутался в том, что они описывают в
формальном ревью и пропустил, что "соответствует" обозначается [+], а
не означает элемент формального ревью, который пакет нарушает.

>> > Пусть он и побочный, но включение его в Fedora привлечет к проекту
>> > достаточно внимания и со стороны разработчиков. Идеальным вариантом мне
>> > представляется добавление реализации арифметического кодирования в
>> > libjpeg-turbo.
>> У меня не столь оптимистичный взгляд. Арифметическое кодирование пока
>> еще покрыто патентами, которые либо истекли, либо истекают в этом году
>> (Ricoh, 1993), но реальное состояние не очень понятно, пусть и
>> частично риски были проанализированы в 2008 году при создании Dirac:
>> http://lwn.net/Articles/272973/
>
> На самом деле, если и произойдет слияние лучшего из обох проектов, то
> произойдет это нескоро. В этом вопросе я не оптимист, а реалист...
>
> Кстати, если оценивать состояние с патентами пессимистично, то нашим лучшим
> выбором на ближайший срок был бы как раз переход на libjpeg-turbo. Мы
> получим ощутимый прирост в производительности, ничем не жертвуя взамен:
> - не нужна глобальная пересборка большей части репозитария
> - нет патентных рисков
> - из-за совпадения API и ABI в случае необходимости можно будет так же
> просто переключиться обратно на libjpeg
Да.

>> Что касается "достаточно внимания и со стороны разработчиков" -- я бы
>> выждал хотя бы до ноября. Пока состояние рассылок по jpeg-turbo не
>> дает мне шансов говорить о каком-то прогрессе по сравнению с
>> оригинальным libjpeg.
>
> С моей точки зрения эти проекты настолько разновекторны, что сравнивать их
> прогресс особого смысла нет. libjpeg-turbo - это ускоренная в реальной
> жизни, а не в теории, реализация алгоритмов. Мы получаем ускорение, и
> заметное, показа существующих джипегов. Оригинальный libjpeg в этом отстает,
> но новые арифметически кодированные файлы получат ускорение за счет меньшего
> размера (меньшее время считывания в ОЗУ может заметно перекрыть отставание
> декодера).
По словам одного из двух авторов оригинального libjpeg, сейчас остался
всего один человек, работающий над libjpeg, и тот не идет на
совместную деятельность. Фактически, это означает, что новым
поколением libjpeg будет скорее всего libjpeg-turbo, поскольку он
устраивает всех с практической точки зрения. Увы, это не решает
проблему с отсутствием разработчиков, кроме Адама Ткаца и
TigerVNC/VirtualGL больше пока никого нет. Даже этот "один из двух
авторов" заявил в мае, что он радостно поддержит libjpeg-turbo, если
не надо будет его разрабатывать.

> Я бы не стал ждать до ноября с выкладыванием libjpeg-turbo в репозитарий.
> Чем раньше и большее количество пользователей начнут его тестировать - тем
> лучше.
Конечно.

>>
>> Мы тоже пытаемся понять и сделать выбор у себя на работе :)
>
> Коллеги, я готов выложить libjpeg-turbo в репозитарий. Да, из-за необходимых
> Obsoletes он начнет вытеснять libjpeg. Поэтому это не просто еще один пакет
> в сизифе "на пощупать". Его наличие там подразумевает, что мы двигаемся к
> его массовому тестированию и замене им стандартного libjpeg в следующих
> дистрибутивах...
Мы тут  посмотрели немного на ситуацию вокруг libjpeg, с учетом
коментариев со стороны ffmpeg
(http://hardwarebug.org/2009/08/04/ijg-is-back/ и
http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/ ),
которые пусть и немного несправедливы, отмечают реальные проблемы. Я
все больше склоняюсь к тому, чтобы переместить акцент на
libjpeg-turbo. Помимо оптимизаций есть и необходимость улучшать API, а
это нужно делать с живым апстримом.

> Поэтому я жду либо аргументированного ветирования такого перехода, либо
> одобрения...
Вето нет.

-- 
/ Alexander Bokovoy