Чернильница №48

[Zhek@Ch]

По случаю выпущенной не так давно новой версии редактора векторной графики Inkscape было взято интервью у разработчиков. Участники проекта поделились планами на ближайшее будущее, подробно рассказали о проектах Google Summer of Code этого года и не забыли о впечатлениях от конференции Libre Graphics Meeting. Избежать откровений, как обычно, не удалось.

О прошлом, настоящем и будущем

Джошуа Андлер (Joshua Andler) активно участвует в проекте с момента его основания, т.е. с 2003 года. В августе он в третий раз исполнил роль руководящего выпуском новой версии Inkscape (0.48) и, по сути, уже некоторое время неформально руководит проектом.

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

 На самом деле, ничего в политике выпуска новых версий не изменилось. Просто некоторое время назад было принято решение, что цикл разработки 0.49 будет ещё одним долгим и посвящённым реструктуризации и чистке кода. Поэтому было решено побыстрее выпустить 0.48 с новыми функциями и затем просто выпускать обновления к нему, чтобы сконцентрироваться над подготовкой 0.49.

 В 0.49 уже интегрирован прошлогодний проект GSoC (Google Summer of Code) по поддержке D-BUS, и его доводка будет одной из главных задач. Основной головной болью будет поддержка D-BUS в Windows, но здесь мы рассчитываем на опыт проекта Inkboard-NG (проект по переписыванию функции коллективного рисования -- прим.ред.).

 Кроме этого необходимо использовать код, написанный в рамках других проектов GSoC, а также проект по управлению растровыми изображениями, написанный студентами из Ecole Centrale Lyon. Заодно можно будет посмотреть, от каких внутренних копий внешних библиотек стоит отказаться. Надо также пересмотреть принцип записи данных SVG, ну и как обычно хватает ошибок, которые следует исправить.

 Похоже, что добрая половина старой команды, которая начала проект, уже не участвует в проекте. В то же время достаточно много новых функций пишется в рамках Google Summer of Code. Насколько я заметил, в проекте есть несколько студентов, неоднократно участвовавших в GSoC. Правильным ли в таком случае будет вывод, что благодаря GSoC формируется новое ядро разработчиков?

 Часть исходной команды разработчиков Inkscape переключилась на работу над lib2geom (библиотека для геометрических вычислений, используемая Inkscape -- прим. ред.), так что они по-прежнему связаны с проектом, но опосредованно. Остальные реализовали в программе всё, что лично им было интересно, поэтому их активность в проекте снизилась.

 

Google Summer of Code -- потрясающий способ нахождения нового поколения разработчиков для проекта Inkscape. С этим поколением приходят новые идеи и новая мотивация. Хотя со временем это поколение, конечно, тоже остынет к работе.

 Насколько я могу судить, изначально Inkscape разрабатывался как редактор SVG с заметным уклоном в экранную графику, по причине чего стал стандартом де-факто для создания значков и элементов брендинга в Linux. Вместе с тем, в последние годы наметился уклон в техническое рисование: улучшенное прилипание (особенно в 0.47 и 0.48), улучшенная работа с сетками, импорт/экспорт DXF и т.д. -- словом, функции, которые чаще встречаются в программах вроде Microsoft Visio и Corel DESIGNER. Существует ли некое целостное видение Inkscape как продукта, которое говорит, где остановиться, а где развивать начатое?

 Я бы сказал так: видение проекта состоит в том, чтобы сделать Inkscape лучшим редактором SVG. Но у каждого разработчика свои представления о будущем программы. Отдельные функции, относящиеся к техническому иллюстрированию, скорее отражают личные потребности разработчиков, нежели сообщества.

 В реальности, когда разработчик руководствуется личной мотивацией, на выходе получается код более высокого качества, причём поддерживаемый. Надеюсь, что в будущем не только повысится совместимость с SVG, но и увеличится количество важных функций.

 Многих пользователей запутывает нумерация версий программы. Люди приходят с опытом работы в программах вроде Adobe Illustrator и Corel DRAW, где версий с номером 0.<что-то> не бывает в принципе. Поэтому Inkscape часто не воспринимается как программа, готовая к использованию. Что об этом думает команда?

 Мы уже давно определились, что номера версий отражают степень поддержки программой спецификации SVG. Сейчас Inkscape как средство создания SVG совершенно не отвечает статусу "1.0". Вместе с тем, если абстрагироваться от SVG и рассматривать программу как обычный редактор векторной графики, мы давно перешли отметку 1.0. Думаю, что ближе к выпуску 0.50 мы пересмотрим принцип нумерации. Тем более, при существующем положении дел мы вряд ли в обозримом будущем добьёмся поставленной цели.

 
Работа над ошибками
 
Несколько людей в сообществе занимаются разбором поступающих отчётов об ошибках: они сортируют их и определяют приоритетность, расставляют метки, запрашивают уточняющую информацию и так далее. Один из этих людей -- Николя Дюфуа (Nicolas Dufour).

 Николя, что ты можешь сказать об участии сообщества в бета-тестировании последней выпущенной версии?

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

 По всей видимости конечные пользователи предпочитают стабильные версии, а не бета-версии для тестирования, что легко понять, особенно когда они используют Inkscape профессионально. Но в результате они сталкиваются с ошибками не в бета-версии, а в той, которая считается стабильной. А это, конечно, сказывается на имидже. Выпуск промежуточных версий с исправлением ошибок мог бы решить часть проблемы, даже если это прибавит работы всей команде.

 Сильно прибавит?

 Насколько я заметил, пользователи склонны считать, что у проектов вроде Inkscape, GIMP или Scribus много хорошо организованных разработчиков, которые знают обо всех возможных ошибках. Признаться, я и сам так считал, пока не влился в проект. К сожалению, в реальности всё совсем не так. Поэтому нам нужно поддерживать в пользователях мотивацию сообщать об ошибках (и голосовать за уже оставленные отчёты). Ценно любое участие, даже если это всего лишь отчёт об ошибке. И как знать -- может быть, это станет первым шагом к дальнейшему сотрудничеству!

 
Проекты Google Summer of Code
 
В этом году у Inkscape три сравнительно успешных проекта Google Summer of Code. Все они так или иначе связаны с улучшением производительности. Три студента, работавших над проектами -- Кшиштоф Косиньский (Krzysztof Kosinski), Вангелис Катсикарос (Vangelis Katsikaros) и Абхишек Шарма (Abishek Sharma).

 Ранее уже предпринимались попытки повысить производительность Inkscape -- как успешные, так и не слишком. Вы взялись за эту проблему одновременно с нескольких сторон. Не могли бы вы рассказать подробнее о своей работе?

 Кшиштоф: Узким местом Inkscape всегда был рендеринг. До сих пор Inkscape использовал собственную библиотеку для растеризации и геометрических вычислений под названием livarot. К сожалению, она была ужасно документирована, не слишком быстра и написана крайне неряшливо, что делало её улучшение практически нереальным. Кроме того, в ней не предусматривалось аппаратное ускорение рендеринга. Часть livarot, отвечающая за геометрические вычисления, к моменту начала работы над проектом уже была по большей части заменена на гораздо более удачную библиотеку 2Geom, но по-прежнему использовался старый код растеризации.

 Сейчас библиотека Cairo становится в свободном ПО основным API двухмерной векторной графики, а в только что вышедшей новой стабильной версии есть cairo-gl -- механизм аппаратного ускорения на основе OpenGL. Мы приняли решение, что в долгосрочной перспективе выгоднее переключиться на использование Cairo. Это было основным предметом моей работы по программе GSoC в этом году.

 

В рамках своего проекта я завершил переход на отрисовку с помощью Cairo, включая фильтры SVG. Теперь при отрисовке всех фильтров выполняется распараллеливание вычислений между ядрами процессора с помощью OpenMP. Это дало заметный прирост производительности ряда примитивов фильтров (особенно ускорился примитив Морфология). Портирование Inkscape на Cairo выявило ряд недочётов в Cairo, над исправлением которых я сейчас работаю.

 Переход на Cairo дал прирост в скорости рендеринга и для обычных объектов -- всё-таки, Pixman, движок рендеринга Cairo, заметно быстрее livarot. Скорость отрисовки объектов с плоской заливкой ускорилась примерно на 50%, для объектов с градиентной заливкой -- ещё больше.

 После исправления некоторых ошибок в рендеринге с помощью Cairo я планирую переключиться на реализацию аппаратно-ускоренных фильтров на OpenCL. При условии использования cairo-gl это даст нам возможность полностью перенести рендеринг на GPU.

 Хотя OpenCL обычно считается API для вычислений на GPU, AMD выпускает драйверы OpenCL для процессоров x86, работающие и на процессорах Intel. В таком случае фильтры на основе OpenCL могли бы повысить производительность и на бюджетных графических картах.

 Вангелис. Мой проект посвящён тому, как программа выбирает, какую часть документа надо отрисовывать. Из всех фигур в файле Inkscape отбирает те, которые видны в окне документа, а затем отрисовывает их на экране. Задача эффективного выбора объектов на плоскости уже решена в геоинформационных системах, для чего в них часто используется индексирование по принципу R-деревьев.

 Задачей моего проекта как раз является использование R-дерева или иной методики индексирования в Inkscape. В настоящее время Inkscape выполняет полное сканирование объектов файла, чтобы найти объекты, которые должны быть отрисованы. Этот поиск, особенно в паре с собственно рендерингом, может существенно замедлить работу Inkscape, что особенно заметно при работе с большими файлами, такими как использующиеся в OpenStreetMaps.

 Мне удалось изучить, как именно Inkscape выполняет рендеринг, и где именно нужно выполнять индексирование. Для индексирования я собираюсь использовать библиотеку spatialindex, которая используется в проекте gispython. Надеюсь, что к середине следующего месяца мне удастся предоставить код для следующей версии Inkscape.

 Пользователям свойственно положительно оценивать новые версии программ по новым функциям и повышенной надёжности работы, но, как правило, они ничего не знают о внутренней работе над программой и о том, как она влияет на разработку приложения в целом. Абхишек, ты не мог бы рассказать о своём проекте GSoC и о том, чего тебе удалось достичь?

 Abhishek: В сложных приложениях принято разделять функциональность на модули и организовывать их коммуникацию. В текущем коде Inkscape полностью разделённых модулей практически нет, поэтому моей первой задачей было создание окружения, в котором создание и работа таких модулей были бы возможны. В рамках этой задачи я переписал часть кода Inkscape на C++, в частности, SPLayer.

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

 
От руководства к программированию
 
Большинству пользователей Inkscape Тавмжонг Бах (Tavmjong Bah) известен преимущественно как автор очень подробного руководства пользователя по программе, которое он обновляет к каждой новой версии.

 Тав, для версии 0.48 ты частично переписал и заметно улучшил инструмент работы с текстом, добавив числовое управление кернингом, трекингом, интерлиньяжем, вращением глифов, а также верхний и нижний индексы. Каково это -- после стольких лет работать над большим проектом в качестве программиста?

 Просто здорово! Действительно, моё участие в работе над кодом со временем возросло. Впервые я начал разбираться с ним, когда мне нужно было понять некоторые документируемые моменты. С течением времени я заинтересовался исправлением ошибок, которые имели для многих пользователей принципиальное значение -- например, экспортом в PostScript и PDF.

 Основной проблемой при работе над кодом была его сложность. Если до сих пор мне приходилось иметь дело лишь с парой файлов, где всё было очевидно, то в этот раз я столкнулся с тем, что код очень плохо документирован, а если комментарии и появляются, то в виде строк «ТУТ НАДО БЫ ИСПРАВИТЬ». Работа над контекстной панелью параметров текста была намного сложнее всего, что я делал до того.

 Как ты считаешь, получится ли у тебя применить полученный опыт на практике при работе над чем-то ещё?

 Да, определённо. Сейчас меня больше всего интересует генерирование программой документов SVG, которые можно использовать в Интернете.

 
LGM2010
 
На конференции Libre Graphics Meeting 2010, которая прошла в конце мая в Брюсселе, встретились некоторые активные участники сообщества и разработчики, многие из них -- впервые в жизни. Среди них были: Йохан Энгелен (Johan Engelen), Яспер ван де Гронде (Jasper van de Gronde), Иван Луэт (Ivan Louette), Элиза Годой де Кастро Герра (Elisa Godoy de Castro Guerra), Седрик Жеми (Cedric Gemy), Тавмжонг Бах (Tavmjong Bah), Фелипе Санчес (Felipe Sanches).

 Похоже, что на LGM2010 был поставлен рекорд по посещаемости участниками проекта Inkscape. К тому же, многие из вас встретились друг с другом впервые в жизни. Какое прямое и опосредованное влияние эта встреча оказала на проект?


 Яспер: За себя могу сказать, что лучше стал понимать других разработчиков и пользователей (!) программы. Очень полезной оказалась и встреча с участниками рабочей группы W3C SVG. Например, для меня стало очевидным, что они рассматривают SVG как нормальный редактируемый формат данных, что могло бы привести к появлению в нём таких элементов как слои (в настоящее время слои в Inkscape реализованы как группы со специальным атрибутом, см. статью по теме -- прим.ред.).

 

Йохан: Для меня эта конференция LGM первая в жизни, и с другими разработчиками Inkscape я тоже до сих пор не был знаком лично. Эта встреча вдохновила меня на продолжение работы над программой. В последние месяцы моя активность заметно угасла. Но после того, как я услышал много новых идей и повстречал людей, которых до того знал лишь по переписке, мне захотелось вернуться в проект. Достаточно интересно было пообщаться с сообществом пользователей напрямую, а результатом всего этого стала работа над динамическим контурным эффектом PowerStroke (контур с переменной толщиной -- прим.ред.). Кроме того, я обсудил с Яспером возможность совместной работы над кривыми диффузии, но продолжения этот разговор пока что не получил.

 Во время конференции прошёл мастер-класс для начинающих пользователей? Какие остались от него впечатления?

 Элиза: Было очень интересно, потому что мы успели сделать просто очень много всего: посмотреть, как работают другие, узнать, с каким опытом они приходят и с какими сложностями сталкиваются, для чего пытаются использовать программу, что у них уже получается, помочь им в освоении программы. Примерно посередине мастер-класса пришёл Жан Гали из проекта Scribus и между делом объяснил, как лучше всего использовать Inkscape в паре со Scribus.

# linuxgraphics.ru

# linux.org.ru