<br><br><div class="gmail_quote">2010/7/6 Alexander Bokovoy <span dir="ltr"><<a href="mailto:ab@altlinux.org" target="_blank">ab@altlinux.org</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2010/7/5 Victor Forsiuk <<a href="mailto:force@altlinux.org" target="_blank">force@altlinux.org</a>>:<br>
<div>> 2010/7/5 Alexander Bokovoy <<a href="mailto:ab@altlinux.org" target="_blank">ab@altlinux.org</a>><br>
>><br>
>> Редхат, руками Адама Ткаца, занялся jpeg-turbo.<br>
> И даже уже принял решение перейти на нее в Fedora 14.<br>
</div>Да, правда соответствующая бага в редхатовской багзиле ужасает.<br></blockquote><div><br>Это какая? Я смотрел 600243.<br><br>BTW: <a href="http://fedoraproject.org/wiki/Features/libjpeg-turbo" target="_blank">http://fedoraproject.org/wiki/Features/libjpeg-turbo</a><br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
>> Главный вопрос, который сейчас стоит -- это кто же будет на самом деле<br>
>> апстримом для свободной реализации libjpeg? оригинальный, но не<br>
>> работающий в том направлении, которое нужно реальным потребителям,<br>
>> libjpeg v8 или TigerVNC, для которого jpeg-turbo пусть и необходимый,<br>
>> но все же побочный продукт?<br>
><br>
> Пусть он и побочный, но включение его в Fedora привлечет к проекту<br>
> достаточно внимания и со стороны разработчиков. Идеальным вариантом мне<br>
> представляется добавление реализации арифметического кодирования в<br>
> libjpeg-turbo.<br>
</div>У меня не столь оптимистичный взгляд. Арифметическое кодирование пока<br>
еще покрыто патентами, которые либо истекли, либо истекают в этом году<br>
(Ricoh, 1993), но реальное состояние не очень понятно, пусть и<br>
частично риски были проанализированы в 2008 году при создании Dirac:<br>
<a href="http://lwn.net/Articles/272973/" target="_blank">http://lwn.net/Articles/272973/</a><br></blockquote><div><br>На самом деле, если и произойдет слияние лучшего из обох проектов, то произойдет это нескоро. В этом вопросе я не оптимист, а реалист...<br>
<br>
Кстати, если оценивать состояние с патентами пессимистично, то нашим лучшим выбором на ближайший срок был бы как раз переход на libjpeg-turbo. Мы получим ощутимый прирост в производительности, ничем не жертвуя взамен:<br>
- не нужна глобальная пересборка большей части репозитария<br>- нет патентных рисков<br>- из-за совпадения API и ABI в случае необходимости можно будет так же просто переключиться обратно на libjpeg<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Что касается "достаточно внимания и со стороны разработчиков" -- я бы<br>
выждал хотя бы до ноября. Пока состояние рассылок по jpeg-turbo не<br>
дает мне шансов говорить о каком-то прогрессе по сравнению с<br>
оригинальным libjpeg.<br></blockquote><div><br>С моей точки зрения эти проекты настолько разновекторны, что сравнивать их прогресс особого смысла нет. libjpeg-turbo - это ускоренная в реальной жизни, а не в теории, реализация алгоритмов. Мы получаем ускорение, и заметное, показа <i>существующих</i> джипегов. Оригинальный libjpeg в этом отстает, но <i>новые</i> арифметически кодированные файлы получат ускорение за счет меньшего размера (меньшее время считывания в ОЗУ может заметно перекрыть отставание декодера).<br>
<br>Я бы не стал ждать до ноября с выкладыванием libjpeg-turbo в репозитарий. Чем раньше и большее количество пользователей начнут его тестировать - тем лучше.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Мы тоже пытаемся понять и сделать выбор у себя на работе :)<br></blockquote><div><br></div></div>Коллеги, я готов выложить libjpeg-turbo в репозитарий. Да, из-за необходимых Obsoletes он начнет вытеснять libjpeg. Поэтому это не просто еще один пакет в сизифе "на пощупать". Его наличие там подразумевает, что мы двигаемся к его массовому тестированию и замене им стандартного libjpeg в следующих дистрибутивах...<br>
<br>Поэтому я жду либо аргументированного ветирования такого перехода, либо одобрения...<br><br><br>