Кроссплатформенная графика с использованием cairo

Хоть Cairo и прикрутили к Gtk, а основное преимущество не использовали: как не учитывал Gtk разрешение дисплея, так и не учитывает. В Gtk3 вроде хотят ввести resolution independence. Вот тогда Cairo покажет себя во всей красе.

/me вышел из анабиоза А где можно почитать про gtk3 ? %)

>/me вышел из анабиоза А где можно почитать про gtk3 ? %)

На ЛОР. Тут всё можно... :)

>>> как не учитывал Gtk разрешение дисплея, так и не учитывает

Что имеется в виду под учётом разрешения?

> В Gtk3 вроде хотят ввести resolution independence

А вот с этого момента пожалуйста поподробнее.

>>> как не учитывал Gtk разрешение дисплея, так и не учитывает

>Что имеется в виду под учётом разрешения?

Имеется в виду, чтобы квадратное на обычном мониторе не становилось прямоугольным на широкоформатном.

>>> Имеется в виду, чтобы квадратное на обычном мониторе не становилось прямоугольным на широкоформатном.

Да вроде у меня такого не наблюдается, или я опять недопонял о чём речь.

Это разве не настройками DPI контролируется? Просьба не бить, если чушь сказал

По сабжу - ценность нулевая, а не совсем адекватный перевод приводит к дополнительной запутанности :(

не совсем так.

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

Подозреваю, что имеются ввиду DPI.
В простонародье, точки на дюйм (т/дм).
На большинстве офисных тачек стоит 96 т/дм, а бывает, что ставят 120 т/дм и выше, например у кого зрение плохое.
Или есть профессиональные мониторы или специфические устройства вывода, у которых т/дм по горизонтали или вертикали могут вообще не совпадать!
И если программа или фреймворк, на котором она реализована это не учитывает, то весь интерфейс просто-напросто "поплывет".

> Поэтому и кайро, что векторная графика при увеличении разрешения не уменьшается в размерах

что-то я сомневаюсь, что мы увидим доступные мониторы с 200 dpi, а тем более 300...400

в 200 dpi я видел только 1 раз viewsonic за $6000

>>> не совсем так.

Запутался я окончательно с вашими объяснениями :)

Короче, у меня всё рисуется так как мне нужно и на обычном мониторе и на широкоформатном с сохранением пропорций и качества изображения, поэтому я видимо и не понимаю о чём речь :)

>А вот с этого момента пожалуйста поподробнее.

На слово "вроде обратил внимание"? Концепция, каким будет Gtk3 ещё не сформировалась. Идей у народа множество. Вот одна из них, мелькала на блоге кого-то из Gtk'шников... Речь шла о API для theme engines или "как нам избавиться от задания размеров в пикселях"... Чем это закончится -- никто не знает :)

>Что имеется в виду под учётом разрешения?

То, чтобы квадрат NxN мм оставался бы квадратом NxN мм и на дисплее с 96x96 DPI, и на 200x200, и на каком-нибудь 100x150 с неквадратным пикселем.

>>> И если программа или фреймворк, на котором она реализована это не учитывает, то весь интерфейс просто-напросто "поплывет"

Ну DPI выставить в GTK+ можно http://linfoline.homedns.org/API/gdk/GdkScreen.html#gdk-screen-get-resolution

А вот чтобы "поплыл" интерфейс написанный на GTK+ я даже не знаю как нужно постараться, он ведь основан на контейнерной упаковке, если виджеты отображаются не правильно значит ошибка при написании программы а не в GTK+, нужно просто внимательно устанавливать параметры упаковки и не задавать размеры виджетов явным образом.

> В Gtk3 вроде хотят ввести resolution independence.

Таймлинк можно?

>Это разве не настройками DPI контролируется? Просьба не бить, если чушь сказал

Контроллируется, но влияет только на шрифты. А, скажем, расстояние между кнопками, или ширина скроллбара сохранит прежний размер в пикселях...

Это приводит к тому, что когда Gtk попадает на мобильный девайс с весьма неслабой разрешающея способностью дисплея, разработчики вынуждены делать под него новые темы оформления, иначе тот же скролбар придётся с лупой искать. Или ещё комичнее: кнопка, которая раньше казалаль нам рельефной, превратиться просто в текст (адекватного размера), обведённый тонкой ниточкой. Попробуй запустить xephyr -dpi 200, и какую-нибудь Gtk'шную или Qt'шную аппликуху в нём.

>Таймлинк можно?

Читай выше. Был трёп в блоге разработчика. И всё. Я же сказал "вроде" :)

>>> с неквадратным пикселем

Как можно нарисовать квадрат неквадратными пикселами, если все размеры задаются в пикселаx, да так чтобы он везде отображался правильно? То есть единицы измерения предлагается использовать разные, а соотношение сторон получать одинаковое?

>А вот чтобы "поплыл" интерфейс написанный на GTK+ я даже не знаю как нужно постараться, он ведь основан на контейнерной упаковке

Да не о том речь. Ничто никуда не поплывёт. Речь о том, чтобы задавать все размеры в мм, а не в пикселях. А, скажем, padding при упаковке ты в пикселях задаёшь. То, что кнопка у тебя обведена каёмкой шириной в N пикселей, захардкожено в движке оформления. Ширина скролбара захаржкожена _в пикселях_. Размеры иконок, даже если оные масштабируемые, -- всё равно, в пикселях.

О том, чтобы можно было весь интерфейс обмерить линейкой, приложив к экрану, и на любом экране получить одинаковые результаты.

> По сабжу - ценность нулевая, а не совсем адекватный перевод приводит к дополнительной запутанности :(

К сожалению да. Тот же небольшой Cairo Tutorial во много раз содержательней.

>Как можно нарисовать квадрат неквадратными пикселами, если все размеры задаются в пикселаx

См. выше: квадрат NxN мм. мм -- это миллиметры.

gtk3 пока зовется иначе(и двояко :)

>>> О том, чтобы можно было весь интерфейс обмерить линейкой, приложив к экрану, и на любом экране получить одинаковые результаты.

А такое вобще возможно? Если все размеры задавать в миллиметрах, то на разных мониторах интерфейс и будет выглядеть по разному. То что декорации виджетов намертво вшиты в GTK+, это да, проблемка. :) Это наверное с помощью стиля можно регулировать, http://linfoline.homedns.org/gtk-2.10-reference-manual-ru/GtkStyle.html хотя точно не скажу, не сталкивался ещё с такой задачей.

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

P.S. Конечно, есть еще третий вариант. Не запускать такое приложение на маленьком экране )

>Если все размеры задавать в миллиметрах, то на разных мониторах интерфейс и будет выглядеть по разному.

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

Пользуясь случаем, спрошу о производительности Cairo. Можно ли её (или какую нибудь другую библиотеку) использовать для отрисовки большого числа (сотни тысяч) точек соединенных линиями? Стоит задача в написании подобия аудиоредактора, вот, подыскиваю инструментарий... Может кто знает, есть ли тесты производительности, сравнения этой библиотеки с другими? Заранее спасибо за ответ :)

>>> Да, по-разному. Но если в измерить в миллиметрах, то одинаково.

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

Насчет сотни не знаю, но порядка 20-30 тыщ рисуется шустро.
Думаю и сотню потянет, особенно если для отрисовки будет использован OpenGL с аппаратным ускорением.

>Допустим у меня два монитора...

Допустим, можно ввести некий _единый_ коэффициент масштабирования... А вообще, вопрос в том, что приорететнее: рационатьность использования пиксельного пространства, или плавность линий :)

>OpenGL с аппаратным ускорением.

Я вот не заметил большой разницы в производительности между Cairo с glitz и с XRender (аппаратно ускоренном).

> Пользуясь случаем, спрошу о производительности Cairo.

http://www.linux.org.ru/view-message.jsp?msgid=1625045

>>> Может кто знает, есть ли тесты производительности, сравнения этой библиотеки с другими? Заранее спасибо за ответ :)

Я пишу программу с использованием Cairo и один человек как раз интересовался скоростью отрисовки, меня этот вопрос не сильно беспокоит, поэтому я предложил ему попробовать и высказать своё мнение, вроде его всё устроило. Но это всё конечно чисто субъективно визуальное восприятие.

http://www.linux.org.ru/jump-message.jsp?msgid=2448902&cid=2475144

>> В Gtk3 вроде хотят ввести resolution independence.

>Таймлинк можно?

Сразу после Qt 12.0

>>> http://www.linux.org.ru/view-message.jsp?msgid=1625045

Эта ссылка двухлетней давности, ты думаешь что ничего с тех пор не изменилось?

> Эта ссылка двухлетней давности, ты думаешь что ничего с тех пор не > изменилось?

Думаю изменилось, как в Qt, так и в Gtk. Но преимущество скорей всего у Qt, слишком уж велик разрыв был.

>Хоть Cairo и прикрутили к Gtk, а основное преимущество не использовали: как не учитывал Gtk разрешение дисплея, так и не учитывает. В Gtk3 вроде хотят ввести resolution independence. Вот тогда Cairo покажет себя во всей красе.

Да, хотели. Но реально это заработало лишь c версии GTK 4.2

> gtk3 пока зовется иначе

Qt?

>Да, хотели. Но реально это заработало лишь c версии GTK 4.2

верни машину времени обратно, негодяй. Я уже хочу eclipse 5.0

>Имеется в виду, чтобы квадратное на обычном мониторе не становилось прямоугольным на широкоформатном.

а что, пиксели на квадратном мониторе квадратные, а на широкоформатнике - прямоугольные?

и там, и там - пикселы одинаковые, вопрос лишь в их количестве в ширише и высоте.

Так оно и не обязательно. Речь идет о рендеринге в заданных размерах на устройствах с разным dpi. А 96 или 200 дпи - не важно.

>Подозреваю, что имеются ввиду DPI. >В простонародье, точки на дюйм (т/дм).

Всегда подозревал, что .RU это что-то другое, а не RUssia.

DPI - они и в Африке dots per inch, а "т/дм" это товары для молодёжи, потому что дм - это общепринятые ДЕЦИМЕТРЫ и нет общепринятого сокращения для DPI.

и там и там пиксели бывают квадратные и прямоугольные.

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

>Я вот не заметил большой разницы в производительности между Cairo с glitz и с XRender (аппаратно ускоренном)

потому что оно только композит через OpenGL. Рендерит в битмап и композит :)

Это разные проблемы.

Для рациональности использования пространства придуман лайаут-менеджер. В гтк оно уже есть и работает.

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

> а что, пиксели на квадратном мониторе квадратные, а на широкоформатнике - прямоугольные?

> и там, и там - пикселы одинаковые, вопрос лишь в их количестве в ширише и высоте.

это на "сейчасных" мониторах такое. Может потом что поменяют?

вот в ЭЛТ мониторах самсунга расстояние по вертикали и горизонтали отличалось (0.2 и 0.26, во всех рекламе писали только меньшую цифру), так же в ЭЛТ мониторах оч.большой диагонали размер пикселя увеличивался от центра в краям. Но там был аналоговый сигнал, который сам направлял луч.

>>> таким образом единственное место, где интерфейс изображается идеально, это монитор дизайнера этого интерфейса

Вывод:

Правильный дизайнер интерфейсов должен иметь всю линейку возможных мониторов и разрешений на которых предполагается использовать его интерфейс :)

Если у вас квадрат, скажем, 100x100 пикселов на мониторе с "родным" разрешением становится неквадратным, то вам не GTK3 надо ждать, а нести свой монитор на помойку.