LINUX.ORG.RU

Cairo 1.0


0

0

Вышла версия 1.0 библиотеки векторной графики с большим будущим на
linux-десктопе. Поддержка Glitz, PS, PDF, Quartz и XCB объявлена
экспериментальной из-за недостаточной cтабильности и проверенности кода
и отключена в сборке по умолчанию. Тестирование экспериментального кода
приветствуется, однако стабильность API не гарантируется в отличие от
основного кода Cairo. Оптимизация коснулась libpixman: значительно
улучшено преобразование изображений, а также добавлен код для работы с
composite из дерева xserver, включающий поддержку mmx для основных
операций. Также окончательно исправлена работы таких операторов как
SOURCE и DEST и добавлена поддержка искусственно-жирных шрифтов.

Объявление о релизе

>>> Подробности

★★★★★

Ответ на: комментарий от kos

>в кедах (точнее QT4) будет Arthur и потом.. возможно.. когда-нибудь.. Cairo

гыгы, а зачем нужен (по гамбургскому счету) cairo как бэкэнд для arthur - это будет лишей прослойкой, на самом деле. ибо arthur и так векторный, и так же имеет тучу бэкэндов, в том числе и поддерживаемые cairo opengl и xrender/xcomposite. хотя для академического интересу цепочка arthur->cairo->glitz->opengl конечно более вычурна и эффектна, чем простое arthur->opengl. ;-)

gassique ★★
()
Ответ на: комментарий от Sof1x

Так по-моему уже пол-ЛОРа на GTK-2.8 перелезла. Нормально у него с
производительностью. Если интересно - замерь gtkperf'ом до и после
обновления.

grob ★★★★★
() автор топика
Ответ на: комментарий от grob

ну я незнаю. у меня только гимп с огненымлисом под гтк бегает. а хотя ща качну если зерколо найду.

Sof1x
()

> Поддержка Glitz, PS, PDF, Quartz и XCB объявлена экспериментальной из-за недостаточной cтабильности и проверенности кода и отключена в сборке по умолчанию.

дык весь рулиз именно в использовании glitz и quartz, если их отключить то от cairo почти никакого толку

JB ★★★★★
()
Ответ на: комментарий от JB

> дык весь рулиз именно в использовании glitz и quartz, если их
> отключить то от cairo почти никакого толку

Ну конечно. А как же Xrender? А если закрыть глаза на скорость (которая
у GTK+-2.8 не меньше, чем у предшественников) и посмотреть на качество
отрисовки и новые возможности? Более того - если тебе хочется:
--enable-glitz или как там и вперед. Только не думай, что от этого GTK+
будет рисовать через glitz. GTK+-2.8 изначально не работало с glitz.
Приложение, которое рисует через cairo, само выбирает cairo backend.
Посмотри в код GTK+-2.8, там вызовы типа cairo_xlib_surface_create
вместо cairo_glitz_surface_create, которые бы использовали glitz.

grob ★★★★★
() автор топика
Ответ на: комментарий от grob

> А как же Xrender? А если закрыть глаза на скорость (которая у GTK+-2.8 не меньше, чем у предшественников)

Да ну? Тут уже неоднократно приводили ссылки на высказывания (в т.ч. и самих разработчиков этого дела), что cairo-рендеринг в gtk-2.8 _медленней_, чем работа напрямую с иксами в 2.6. По причине отсутствия нормального аппаратного ускорения, за исключением glitz.

> GTK+-2.8 изначально не работало с glitz. Приложение, которое рисует через cairo, само выбирает cairo backend.

Какого @#% ?? Т.е. о модульности там речь даже не идет? Тогда зачем вообще было огород городить...

int19h ★★★★
()
Ответ на: комментарий от int19h

Не медленнее, а такой же. Вот например здесь почти все быстрее:
http://osnews.com/permalink.php?news_id=11564&comment_id=17959
С nvidia и включенным RenderAccel у меня на глаз новый GTK+ быстрее.
Glitz-backend просто еще не готов. Он не поддерживает surface resize.
А данный подход, когда приложение выбирает backend логичен, когда
оным может быть PS или PDF.

grob ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Cairo - это было черновое название NT 4.0 :-) В ней обещали сделать объектно-ориентированный интерфейс, объектную файловую систему, она должна была стать многопользовательской и защищенной... Но получилась Windows NT 4.0 :-)

no-dashi ★★★★★
()
Ответ на: комментарий от grob

> А данный подход, когда приложение выбирает backend логичен, когда оным может быть PS или PDF.

Может он и логичен. Но для отрисовки на экран, я хочу _сам_ устанавливать механизм вывода.

int19h ★★★★
()
Ответ на: комментарий от grob

> Когда glitz доделают, наверное его прикрутят.

Так я не понял - если там бэкенд жестко зашит в код и определяется именем вызываемой функции, как его можно "потом" прикрутить кроме поиска-замены по коду и перекомпиляцией?

int19h ★★★★
()
Ответ на: комментарий от anonymous

> Я так понимаю, что теперь легко можно сделать AutoCAD (и просие CAD'ы) под Linux

А в чем была проблема раньше?

И линух тут не при чем - фишка cairo как раз в том, что оно мультиплатформенное.

int19h ★★★★
()
Ответ на: комментарий от int19h

> Так я не понял - если там бэкенд жестко зашит в код и определяется именем вызываемой функции, как его можно "потом" прикрутить кроме поиска-замены по коду и перекомпиляцией?

Наличие системы бакэндов ДАЕТ возможность реализовывать динамический выбор бакэнда, но не обязывает это реализовывать. :-)

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

> Наличие системы бакэндов ДАЕТ возможность реализовывать динамический выбор бакэнда, но не обязывает это реализовывать. :-)

УБИВАТЬ! =/ ;)

int19h ★★★★
()
Ответ на: комментарий от anonymous

кроссплатформенный Автокад клон называется VariCAD

Syncro ★★★★★
()
Ответ на: комментарий от no-dashi

интересно бэкэнд можно будет выбрать каким ним явным образом ?

Syncro ★★★★★
()
Ответ на: комментарий от anonymous

> Нифига себе 8-0

А ты не знал? ;-) Cairo - это codename NT 4. ;-)

//Atrus

anonymous
()
Ответ на: комментарий от anonymous

> Я так понимаю, что теперь легко можно сделать AutoCAD (и просие CAD'ы) под Linux

1. Основные проблемы САПРов - не в том, как нарисовать:)

2. cairo ничем не поможет - там слишком примитивный набор примитивов и операций, для нормального САПРа. Уж opengl - куда лучше. cairo предназначен только для десктопа, где графика обходится относительно скромной графической функциональностью (но при этом должна быть максимально шустрой). САПР может слегка подтормаживать в визуализации, десктоп - нет.

svu ★★★★★
()
Ответ на: комментарий от grob

> С nvidia и включенным RenderAccel у меня на глаз новый GTK+ быстрее.

А у меня с RenderAccel десктоп (X сервер) периодически виснет. 7174 / MX 440 / что еще нужно сказать про ядро.

AlexM ★★★★★
()
Ответ на: комментарий от AP

> А чего, OpenGL уже не в моде?

OpenGL есть не у всех :( а CAD'ы -- нужны очень, а то из-за них на работе приходиться сидеть в мелкомягком поделие.

anonymous
()
Ответ на: комментарий от anonymous

> OpenGL есть не у всех :(

А у кого нет?

plm ★★★★★
()
Ответ на: комментарий от svu

> cairo ничем не поможет - там слишком примитивный набор примитивов и операций, для нормального САПРа.

И ваще, почему люди не пользуются OpenCascade? :)

AP ★★★★★
()

А вот что произойдёт, если я попытаюсь запустить Gnome 2.11.x под XF86Svga из XFree 3.3.6?

Shadow ★★★★★
()
Ответ на: комментарий от Shadow

> А вот что произойдёт, если я попытаюсь запустить Gnome 2.11.x под XF86Svga из XFree 3.3.6?

Оно будет рисовать тебе антиалисенные линии со скоростью одна штука в секунду.

int19h ★★★★
()
Ответ на: комментарий от int19h

> Оно будет рисовать тебе антиалисенные линии
Так почему бы ему не забить на АА? И рисовать просто. Будет уродливо, конечно, но быстро...

Ведь в Windows GDI такое возможно...

Shadow ★★★★★
()
Ответ на: комментарий от Shadow

> Так почему бы ему не забить на АА? И рисовать просто. Будет уродливо, конечно, но быстро...

Тогда зачем он вообще нужен? Рисование с АА - его единственная задача.

anonymous
()
Ответ на: комментарий от anonymous

Как интересно! А мне казалось, что его задача - создание адекватного быстрого, переносимого API. А в итоге мы приходим к тому, что работать с удобным десктопом в Линуксе мы не сможем ни на чём, кроме видеокарточек NVIDIA с закрытыми дарайверами.

Shadow ★★★★★
()
Ответ на: комментарий от Shadow

> Так почему бы ему не забить на АА? И рисовать просто. Будет уродливо, конечно, но быстро...

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

> Ведь в Windows GDI такое возможно...

Хм... а не в GDI+? Я что-то не помню антиалиасинга примитивов в GDI API. А в GDI+, насколько я помню, ситуация аналогичная - если софтина запросила сглаживание, то она его получит, но вот ускоренное оно будет или нет - другой вопрос.

int19h ★★★★
()
Ответ на: комментарий от int19h

Сорри, я не программировал никогда под Виндовс, да и вообще мало программирую...
Но вот, допустим, если программы Open GL запросят AA примитивов, если карточка не умеет этого, они АА не получат... Но и не заметят. Прада, всё от драйверов зависит...
По-моему, что-то тут нетак.

Shadow ★★★★★
()
Ответ на: комментарий от Shadow

> Но вот, допустим, если программы Open GL запросят AA примитивов, если карточка не умеет этого, они АА не получат...

AFAIR как раз получат. И фильтрацию тоже. Даже если она будет сделана полностью в software mode - все равно это будет честная билинейная фильтрация. С соответствующей скоростью....

int19h ★★★★
()
Ответ на: комментарий от int19h

погонял я тут cairogears. Во первых пришлось напильником долго работать, ибо api сменился, makefile кривой. Во вторых собиралось в glitz-ом все. Там где-то 7 тестов. с ключом -glx первые два теста = 15 fps, в остальных по 1500 fps но почему-то черный экран. Копать в чем же дело не было желания. при использовании -image = 24 fps на аналогичных тестах. Все остальное либо сегфолт либо тоже черный экран. -xrender так вообще во всех тестах в сегфолт уходит. Так что я согласен с int19h

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.