Собирал тут boost. Люди, которые меня хорошо знают, удивятся - я же известный boost hater. #gold
Не себе, для дела. Boost требуется для сборки Inkscape, а Inkscape нужен для рендера иконок в теме Adwaita(это, кстати, та еще кольцевая зависимость, потому что иконки требуются для gtk, а gtk нужен для сборки inkscape, ну да ладно). #svg
Для этого пришлось бутстрепнуть B2, оно же бывший bjam. Удивительно, но в ней нет поддержки кросс-компиляции, хотя, конечно, авторы утверждают обратное.
Давайте я поясню, что я имею в виду, когда говорю, что система сборки поддерживает кросс компиляцию: #cross #cmake
* Возможность указать компилятор и cflags - это НЕ поддержка кросс-компиляции, потому что без "раздвоения" сборочного графа это приводит к невозможности собирать проекты, которым требуется строить host тулзы во время сборки(если host != target). cmake, bjam - отличные представители.
* Кросс-компиляция начального уровня - когда сборочная система знает про HOSTCC, TARGETCC, и позволяет описать разные части сборочного графа используя разные *CC. Например, make, ninja(без надстроек над ними), autoconf.
* Кросс-компиляция второго уровня - когда можно для таргета сборки указать, host он, или target, а далее сборочная система сама правильно подставит HOSTCC, TARGETCC. meson - прекрасный представитель.
* "Высшая" кросс-компиляция - когда любым таргетом можно оперировать как в контексте host, так и target. Все будет сделано прозрачно для пользователя. ya, bazel(buck? честно, не знаю так глубоко). Кстати, Mix тоже(с поправкой на то, что не все таргеты в OSS принципиально можно кросс-компилировать).
Теперь к B2/BJAM:
* https://www.bfgroup.xyz/b2/manual/release/index.html#bbv2.tasks.crosscompile - нет разделения на target/host вообще.
* https://github.com/bfgroup/b2/blob/main/bootstrap.sh#L26 - позорище, facepalm, запуск свежесобранной target тулзы для инсталляции ея же.
Не себе, для дела. Boost требуется для сборки Inkscape, а Inkscape нужен для рендера иконок в теме Adwaita(это, кстати, та еще кольцевая зависимость, потому что иконки требуются для gtk, а gtk нужен для сборки inkscape, ну да ладно). #svg
Для этого пришлось бутстрепнуть B2, оно же бывший bjam. Удивительно, но в ней нет поддержки кросс-компиляции, хотя, конечно, авторы утверждают обратное.
Давайте я поясню, что я имею в виду, когда говорю, что система сборки поддерживает кросс компиляцию: #cross #cmake
* Возможность указать компилятор и cflags - это НЕ поддержка кросс-компиляции, потому что без "раздвоения" сборочного графа это приводит к невозможности собирать проекты, которым требуется строить host тулзы во время сборки(если host != target). cmake, bjam - отличные представители.
* Кросс-компиляция начального уровня - когда сборочная система знает про HOSTCC, TARGETCC, и позволяет описать разные части сборочного графа используя разные *CC. Например, make, ninja(без надстроек над ними), autoconf.
* Кросс-компиляция второго уровня - когда можно для таргета сборки указать, host он, или target, а далее сборочная система сама правильно подставит HOSTCC, TARGETCC. meson - прекрасный представитель.
* "Высшая" кросс-компиляция - когда любым таргетом можно оперировать как в контексте host, так и target. Все будет сделано прозрачно для пользователя. ya, bazel(buck? честно, не знаю так глубоко). Кстати, Mix тоже(с поправкой на то, что не все таргеты в OSS принципиально можно кросс-компилировать).
Теперь к B2/BJAM:
* https://www.bfgroup.xyz/b2/manual/release/index.html#bbv2.tasks.crosscompile - нет разделения на target/host вообще.
* https://github.com/bfgroup/b2/blob/main/bootstrap.sh#L26 - позорище, facepalm, запуск свежесобранной target тулзы для инсталляции ея же.
www.bfgroup.xyz
B2 User Manual
👍1
#svg
С иконками, я, конечно, намучался.
* Пути к дефолтным иконкам в тулкитах.
* Какие иконки должны быть.
* Часть иконок в Adwaita лежит в png, часть - в svg, эти множества частично пересекаются. Что выберет то или иное приложение, одному (хз знает кому) известно. В svg лежат ЧБ иконки, в png - цветные.
* Загрузка svg устроена через плагин для gdk-pixbuf. Плагины для него устроены самым ненатуральным образом из всех мне известных(постараюсь написать про то, как извращенно разработчики устраивают загрузку своих плагинов). К сожалению, последняя версия этого плагина, не переписанная на Rust, не очень корректно рендерит последние иконки от Adwaita.
* Отладка "чего там реально загружается" через strace не очень помогает, так как каждая папка с иконками должна содержать индекс.
Так и живем - для качественного рендеринга в png требуется inkscape, для некачественного на лету - Rust.
К сожалению, компилятор Rust у меня сейчас даже не запускается, потому что он принципиально не может быть слинкован статически.
Вся надежда на https://github.com/thepowersgang/mrustc #mrustc, чувак все ближе и ближе к тому, чтобы поддержкать 1.54. Понятное дело, что без borrow checker, но кому оно надо не в процессе разработки? У него своя реализация proc macro(по понятным причинам), не требующая подгрузки .so в компилятор.
Я сейчас остановился на svg иконках с не совсем корректным рендерингом, потому что облизывать Epiphany уже поднадоело(https://wiki.gnome.org/Apps/Web). Надо посмотреть, что ждет на пути сборки Chromium.
Кстати, я почти победил тиринг в Epiphany. Для этого я собрал webkit web process(который занимается непосредственно рендерингом) на gtk4, в котором все лучше с поддержкой opengl/vulkan канвы, а сам браузер с gtk3. Потому что Igalia уже портировала WebKIT на gkt4, а сам браузер - еще нет. Думаю, Igalia подавились бы чем-нибудь на радостях, узнав, что я так делаю. #igalia
С иконками, я, конечно, намучался.
* Пути к дефолтным иконкам в тулкитах.
* Какие иконки должны быть.
* Часть иконок в Adwaita лежит в png, часть - в svg, эти множества частично пересекаются. Что выберет то или иное приложение, одному (хз знает кому) известно. В svg лежат ЧБ иконки, в png - цветные.
* Загрузка svg устроена через плагин для gdk-pixbuf. Плагины для него устроены самым ненатуральным образом из всех мне известных(постараюсь написать про то, как извращенно разработчики устраивают загрузку своих плагинов). К сожалению, последняя версия этого плагина, не переписанная на Rust, не очень корректно рендерит последние иконки от Adwaita.
* Отладка "чего там реально загружается" через strace не очень помогает, так как каждая папка с иконками должна содержать индекс.
Так и живем - для качественного рендеринга в png требуется inkscape, для некачественного на лету - Rust.
К сожалению, компилятор Rust у меня сейчас даже не запускается, потому что он принципиально не может быть слинкован статически.
Вся надежда на https://github.com/thepowersgang/mrustc #mrustc, чувак все ближе и ближе к тому, чтобы поддержкать 1.54. Понятное дело, что без borrow checker, но кому оно надо не в процессе разработки? У него своя реализация proc macro(по понятным причинам), не требующая подгрузки .so в компилятор.
Я сейчас остановился на svg иконках с не совсем корректным рендерингом, потому что облизывать Epiphany уже поднадоело(https://wiki.gnome.org/Apps/Web). Надо посмотреть, что ждет на пути сборки Chromium.
Кстати, я почти победил тиринг в Epiphany. Для этого я собрал webkit web process(который занимается непосредственно рендерингом) на gtk4, в котором все лучше с поддержкой opengl/vulkan канвы, а сам браузер с gtk3. Потому что Igalia уже портировала WebKIT на gkt4, а сам браузер - еще нет. Думаю, Igalia подавились бы чем-нибудь на радостях, узнав, что я так делаю. #igalia
GitHub
GitHub - thepowersgang/mrustc: Alternative rust compiler (re-implementation)
Alternative rust compiler (re-implementation). Contribute to thepowersgang/mrustc development by creating an account on GitHub.
👍2
Недавно рассказывал, что соорудил рендеринг #svg иконок в png, через #inkscape.
Все же, мне этот процесс кажется не очень технологичным:
* Inkscape - overkill по зависимостям
* И, хотя я и сделал, что от пакета с иконками зависит только финальный #realm, все равно, inkscape пересобирается довольно часто, и приводит к пересборке иконок.
* Еще он срет в консоль сообщениями про то, что, мол, не может найти display.
Поэтому я решил найти что-то попроще!
Сначала гугл мне посоветовал https://github.com/cppfw/svgren
На первый взгляд, библиотека неплохая, много чего умеет. Но, к сожалению, ее автор сошел с ума (кстати, а вы уже поняли, что эта моя характеристика почти никогда не несет отрицательной коннотации? Мы тут сумасшедших любим, они делают все самое интересное!):
* Он распилил проект на очень много маленьких зависимостей, которые надо опакетить.
* Так-то оно, может, и неплохо, но он к ним запилил свою систему сборки, с классным названием prorab - https://github.com/cppfw/svgren/blob/master/makefile, и с не менее классным определением библиотек в системе, с чем я уже развлекаться не захотел.
Я решил, что, раз автор меня так не уважает, и не хочет, чтобы я пользовался его кодом - ну, так и быть! Мораль - не выебывайтесь при выборе системы сборки.
Вторым вариантом гугл мне предложил https://github.com/sammycage/lunasvg, на ней я и остановился.
У нее в комплекте поставки есть тулза svg2png, которой мне оказалось достаточно, чтобы поверх нагородить рендеринг иконок.
"Из коробки" мне не понравилось только сглаживание, поэтому я наладил такой вот процесс https://github.com/pg83/ix/blob/main/pkgs/bld/iconker/lunasvg/iconker.py:
* Рендерим иконку в большом разрешении
* Ресайзим через Imagemagic's convert во все нужные разрешения
Заодно оно стало быстрее работать, потому что рендеринг, все же, медленнее, чем resize.
Хорошая, годная, библиотека, подумываю написать поверх нее pixman loader, вместо librsvg-шного.
Все же, мне этот процесс кажется не очень технологичным:
* Inkscape - overkill по зависимостям
* И, хотя я и сделал, что от пакета с иконками зависит только финальный #realm, все равно, inkscape пересобирается довольно часто, и приводит к пересборке иконок.
* Еще он срет в консоль сообщениями про то, что, мол, не может найти display.
Поэтому я решил найти что-то попроще!
Сначала гугл мне посоветовал https://github.com/cppfw/svgren
На первый взгляд, библиотека неплохая, много чего умеет. Но, к сожалению, ее автор сошел с ума (кстати, а вы уже поняли, что эта моя характеристика почти никогда не несет отрицательной коннотации? Мы тут сумасшедших любим, они делают все самое интересное!):
* Он распилил проект на очень много маленьких зависимостей, которые надо опакетить.
* Так-то оно, может, и неплохо, но он к ним запилил свою систему сборки, с классным названием prorab - https://github.com/cppfw/svgren/blob/master/makefile, и с не менее классным определением библиотек в системе, с чем я уже развлекаться не захотел.
Я решил, что, раз автор меня так не уважает, и не хочет, чтобы я пользовался его кодом - ну, так и быть! Мораль - не выебывайтесь при выборе системы сборки.
Вторым вариантом гугл мне предложил https://github.com/sammycage/lunasvg, на ней я и остановился.
У нее в комплекте поставки есть тулза svg2png, которой мне оказалось достаточно, чтобы поверх нагородить рендеринг иконок.
"Из коробки" мне не понравилось только сглаживание, поэтому я наладил такой вот процесс https://github.com/pg83/ix/blob/main/pkgs/bld/iconker/lunasvg/iconker.py:
* Рендерим иконку в большом разрешении
* Ресайзим через Imagemagic's convert во все нужные разрешения
Заодно оно стало быстрее работать, потому что рендеринг, все же, медленнее, чем resize.
Хорошая, годная, библиотека, подумываю написать поверх нее pixman loader, вместо librsvg-шного.
GitHub
GitHub - cppfw/svgren: :camera: SVG rendering library in C++
:camera: SVG rendering library in C++. Contribute to cppfw/svgren development by creating an account on GitHub.
🔥8👍6😁3
commit -m "better"
Недавно рассказывал, что соорудил рендеринг #svg иконок в png, через #inkscape. Все же, мне этот процесс кажется не очень технологичным: * Inkscape - overkill по зависимостям * И, хотя я и сделал, что от пакета с иконками зависит только финальный #realm…
Мужик сказал - мужик сделал!
Запилил я gdk pixbuf #svg loader поверх #lunasvg!
В процессе, конечно, узнал много чего интересного, чем и спешу поделиться.
Короткая предыстория:
* Сперва у меня вообще не было рендера svg, потому что #rsvg перешел на Rust, а его у меня (пока?) нет.
* Потом я научился использовать довольно старую версию librsvg, которая была написана на C, и глючила, что пиздец - 1/4 иконок была отренжерена с какими-то артефактами. Это, конечно, то еще достижение, учитывая простоту формата svg.
* Потом я научился готовить для всех scalable иконок png заранее, с помощью inkscape. Примерно для 1/4 оставшихся использовался старый rsvg render, с баглом и артефактами.
* Потом я нашел замечательную #lunasvg, и перешел на нее для рендеринга png, а то, что мой процесс не находил, или были нужны какие-то особенные разрешения, использовался старый rsvg.
* (мы находимся тут) -> png рендерятся с помощью lunasvg, остатки - тоже.
https://github.com/pg83/ix/blob/main/pkgs/lib/lunasvg/gdk/io.cpp - вот код клея между lunasvg и gdk-pixbuf.
БОльшую часть кода я написал за полчаса, а потом еще часа 3 трахался за последние 5 строк кода, без которых на экране был мусор:
* Примерно полтора часа - это "нормальная" отладка - разбирательство с тем, в каком формате поверхность отдает lunasvg, в каком ожидает GdkPixbuf, и как их "поженить", разбирательство с моделью владения памятью в glib(чтобы не текло и не ездило по use-after-free), и с обработкой ошибок в ней же.
* А вторые полтора часа - это какая-то совершенно безумная ебала, когда, на первый взгляд, я делаю все правильно, при этом, знаю, что command line часть lunasvg родила корректный png, но, если отрендерить его в динамике моим кодом, то на экране - мусор.
В какой-то момент времени я остановился, и подумал: "А какое бы безумное действие я мог бы совершить на месте авторов gtk, чтобы у меня ничего не работало"?
Единственное, что мне пришло в голову - что они, зачем-то, портят xml с svg, перед тем, как его передать мне. Ну потому что как еще объяснить факт, что pixmap data получается разная?
Sooka! Sooka! Аааа!
https://github.com/GNOME/gtk/blob/main/gtk/gdkpixbufutils.c#L249
Короче, они манглят svg во вложенный svg в виде base64 блоба. КМК, это сделано затем, чтобы указать уникальный размер для рендеринга. Да, да, в scalable vector graphics есть width, и height, чтобы им пусто было.
Я, конечно, решил, что раз эти негодяи формируют xml через printf, то парсить я его буду регулярками. https://github.com/pg83/ix/blob/main/pkgs/lib/lunasvg/gdk/io.cpp#L93 (да, да, это точно надо занести в upstream)
После этого почти(в следующей серии!) все заработало, иконки выглядят очень хорошо, всяко лучше, чем в бажной и глючной старой librsvg.
Запилил я gdk pixbuf #svg loader поверх #lunasvg!
В процессе, конечно, узнал много чего интересного, чем и спешу поделиться.
Короткая предыстория:
* Сперва у меня вообще не было рендера svg, потому что #rsvg перешел на Rust, а его у меня (пока?) нет.
* Потом я научился использовать довольно старую версию librsvg, которая была написана на C, и глючила, что пиздец - 1/4 иконок была отренжерена с какими-то артефактами. Это, конечно, то еще достижение, учитывая простоту формата svg.
* Потом я научился готовить для всех scalable иконок png заранее, с помощью inkscape. Примерно для 1/4 оставшихся использовался старый rsvg render, с баглом и артефактами.
* Потом я нашел замечательную #lunasvg, и перешел на нее для рендеринга png, а то, что мой процесс не находил, или были нужны какие-то особенные разрешения, использовался старый rsvg.
* (мы находимся тут) -> png рендерятся с помощью lunasvg, остатки - тоже.
https://github.com/pg83/ix/blob/main/pkgs/lib/lunasvg/gdk/io.cpp - вот код клея между lunasvg и gdk-pixbuf.
БОльшую часть кода я написал за полчаса, а потом еще часа 3 трахался за последние 5 строк кода, без которых на экране был мусор:
* Примерно полтора часа - это "нормальная" отладка - разбирательство с тем, в каком формате поверхность отдает lunasvg, в каком ожидает GdkPixbuf, и как их "поженить", разбирательство с моделью владения памятью в glib(чтобы не текло и не ездило по use-after-free), и с обработкой ошибок в ней же.
* А вторые полтора часа - это какая-то совершенно безумная ебала, когда, на первый взгляд, я делаю все правильно, при этом, знаю, что command line часть lunasvg родила корректный png, но, если отрендерить его в динамике моим кодом, то на экране - мусор.
В какой-то момент времени я остановился, и подумал: "А какое бы безумное действие я мог бы совершить на месте авторов gtk, чтобы у меня ничего не работало"?
Единственное, что мне пришло в голову - что они, зачем-то, портят xml с svg, перед тем, как его передать мне. Ну потому что как еще объяснить факт, что pixmap data получается разная?
Sooka! Sooka! Аааа!
https://github.com/GNOME/gtk/blob/main/gtk/gdkpixbufutils.c#L249
Короче, они манглят svg во вложенный svg в виде base64 блоба. КМК, это сделано затем, чтобы указать уникальный размер для рендеринга. Да, да, в scalable vector graphics есть width, и height, чтобы им пусто было.
Я, конечно, решил, что раз эти негодяи формируют xml через printf, то парсить я его буду регулярками. https://github.com/pg83/ix/blob/main/pkgs/lib/lunasvg/gdk/io.cpp#L93 (да, да, это точно надо занести в upstream)
После этого почти(в следующей серии!) все заработало, иконки выглядят очень хорошо, всяко лучше, чем в бажной и глючной старой librsvg.
GitHub
ix/pkgs/lib/lunasvg/gdk/io.cpp at main · pg83/ix
ix package manager. Contribute to pg83/ix development by creating an account on GitHub.
👍10🔥6👌3😁2👏1
commit -m "better"
Мужик сказал - мужик сделал! Запилил я gdk pixbuf #svg loader поверх #lunasvg! В процессе, конечно, узнал много чего интересного, чем и спешу поделиться. Короткая предыстория: * Сперва у меня вообще не было рендера svg, потому что #rsvg перешел на Rust…
Продолжение истории про #lunasvg. #svg
Я закончил на том, что у меня часть иконок была отренжерена через lunasvg в процессе построения пакета с иконками, а часть(которая вне этого пакета) - в процессе работы приложения.
Проблема была в том, что иконки, отренжеренные в динамике, были не черные, а слегка желтоватые. С таким уклоном в сепию, как будто-то кто сблендил чутка желтого цвета на поверхность.
Причем я совершенно точно уверен, что цвета я отдал правильные, я вывел их на консоль, и сравнил с тем, что шло в сгенеренных png. Уклона в сепию в этих цветах не было.
Я бы тут хотел ткнуть вас куском кода из rsvg/cairo/gdk, который страдает такой херней, но я не сумел, там все слишком запутано.
Чего только стоят несовпадения ARGB/RGBA, где-то используется premultiplied alpha, где-то - нет, premultiplied alpha по разным формулам, все эти поверхности постоянно туда-сюда преобразуются.
Я решил просто потвикать r, g, b, a каналы в разные стороны, и посмотреть, что получится.
В процессе я выяснил:
* g, b каналы никак не использовались, ну, то есть, я мог туда записать все, что угодно.
* r канал давал изменение от цвета фона к ярко-желтому цвету. 0 - фон, 255 - ярко-желтый(нет, это не cmyk, и не прочие модели, по крайней мере, не те, что я знаю).
* alpha канал работал, как надо.
Мое лучшее предположение - что рендеринг symbolic иконки - это, собственно, отбрасывание r, g, b, и использование только alpha компоненты для блендинга между фоном и цветом для рисования.
Желтый? Хер его знает, может, для дебага, может, я вообще неверно все понял.
В итоге, решение вида "оставить только alpha канал для svg, которые загружаются как symbolic иконки", вполне себе сработало, я с лупой не нашел отличий. https://github.com/pg83/ix/blob/main/pkgs/lib/lunasvg/gdk/io.cpp#L100
Так-то это достаточно логично - а как еще наиболее дешево "оконтурить" произвольную svg?
Где это происходит в связке rsvg/gdk/cairo, я не нашел, они большие мастера прятать такое говнецо.
Я закончил на том, что у меня часть иконок была отренжерена через lunasvg в процессе построения пакета с иконками, а часть(которая вне этого пакета) - в процессе работы приложения.
Проблема была в том, что иконки, отренжеренные в динамике, были не черные, а слегка желтоватые. С таким уклоном в сепию, как будто-то кто сблендил чутка желтого цвета на поверхность.
Причем я совершенно точно уверен, что цвета я отдал правильные, я вывел их на консоль, и сравнил с тем, что шло в сгенеренных png. Уклона в сепию в этих цветах не было.
Я бы тут хотел ткнуть вас куском кода из rsvg/cairo/gdk, который страдает такой херней, но я не сумел, там все слишком запутано.
Чего только стоят несовпадения ARGB/RGBA, где-то используется premultiplied alpha, где-то - нет, premultiplied alpha по разным формулам, все эти поверхности постоянно туда-сюда преобразуются.
Я решил просто потвикать r, g, b, a каналы в разные стороны, и посмотреть, что получится.
В процессе я выяснил:
* g, b каналы никак не использовались, ну, то есть, я мог туда записать все, что угодно.
* r канал давал изменение от цвета фона к ярко-желтому цвету. 0 - фон, 255 - ярко-желтый(нет, это не cmyk, и не прочие модели, по крайней мере, не те, что я знаю).
* alpha канал работал, как надо.
Мое лучшее предположение - что рендеринг symbolic иконки - это, собственно, отбрасывание r, g, b, и использование только alpha компоненты для блендинга между фоном и цветом для рисования.
Желтый? Хер его знает, может, для дебага, может, я вообще неверно все понял.
В итоге, решение вида "оставить только alpha канал для svg, которые загружаются как symbolic иконки", вполне себе сработало, я с лупой не нашел отличий. https://github.com/pg83/ix/blob/main/pkgs/lib/lunasvg/gdk/io.cpp#L100
Так-то это достаточно логично - а как еще наиболее дешево "оконтурить" произвольную svg?
Где это происходит в связке rsvg/gdk/cairo, я не нашел, они большие мастера прятать такое говнецо.
GitHub
ix/pkgs/lib/lunasvg/gdk/io.cpp at main · pg83/ix
ix package manager. Contribute to pg83/ix development by creating an account on GitHub.
👍4🐳3❤2🔥2🌭1🍌1
commit -m "better"
Недавно рассказывал, что соорудил рендеринг #svg иконок в png, через #inkscape. Все же, мне этот процесс кажется не очень технологичным: * Inkscape - overkill по зависимостям * И, хотя я и сделал, что от пакета с иконками зависит только финальный #realm…
Я тут, на досуге, продолжил возню с #svg.
Не то чтобы меня не устраивало, как работает #lunasvg, но вот этот вот svgren, о котором шла речь в предыдущем посте, он использует AGG https://en.wikipedia.org/wiki/Anti-Grain_Geometry в качестве канвы для отрисовки, а я, знаете ли, испытываю к ней нежные чувства (не спрашивайте). Ну и мне показалось прикольным, если за рендерингом svg у меня будет стоять это произведение искусства!
Вот список зависимостей, которые пришлось подтащить для сборки этой самой svgren - https://github.com/pg83/ix/tree/main/pkgs/lib/svgren Это все - адовые велосипеды от того же автора, что и сам svgren.
Знаете, я долго сдерживал смех, пока клал эти библиотеки, одну за одной, но вот когда мне пришлось написать нечто вот такое в своем коде - https://github.com/cppfw/svgren/blob/master/tests/render/main.cpp#L120-L121, я уже не смог сдерживаться, и пока отложил порт.
Не то чтобы меня не устраивало, как работает #lunasvg, но вот этот вот svgren, о котором шла речь в предыдущем посте, он использует AGG https://en.wikipedia.org/wiki/Anti-Grain_Geometry в качестве канвы для отрисовки, а я, знаете ли, испытываю к ней нежные чувства (не спрашивайте). Ну и мне показалось прикольным, если за рендерингом svg у меня будет стоять это произведение искусства!
Вот список зависимостей, которые пришлось подтащить для сборки этой самой svgren - https://github.com/pg83/ix/tree/main/pkgs/lib/svgren Это все - адовые велосипеды от того же автора, что и сам svgren.
Знаете, я долго сдерживал смех, пока клал эти библиотеки, одну за одной, но вот когда мне пришлось написать нечто вот такое в своем коде - https://github.com/cppfw/svgren/blob/master/tests/render/main.cpp#L120-L121, я уже не смог сдерживаться, и пока отложил порт.
Wikipedia
Anti-Grain Geometry
graphics library
😁8👍3❤2🤔1🤡1🐳1
commit -m "better"
Продолжение истории про #lunasvg. #svg Я закончил на том, что у меня часть иконок была отренжерена через lunasvg в процессе построения пакета с иконками, а часть(которая вне этого пакета) - в процессе работы приложения. Проблема была в том, что иконки, отренжеренные…
Я как-то давно рассказывал, что у меня в репе нет librsvg, и что #svg иконки я отрисовываю без нее.
Вот, раз уж добавил в репозиторий skia (https://t.iss.one/itpgchannel/2035), то было грех не запилить +1 рендер иконок, уже с ее помощью:
https://github.com/pg83/ix/blob/main/pkgs/bin/skia/svg/ss.cpp - это сама тулза, которая рендерит svg через #skia.
https://github.com/pg83/ix/tree/main/pkgs/bld/iconker - заодно похвастаюсь, сколько у меня вообще сейчас способов отрисовать svg иконку - через inkscape, через #lunasvg, через resvg (библиотека на Rust, лучше, чем librsvg, https://github.com/RazrFalcon/resvg), теперь вот через skia, ну и через #svgren.
Рендер через skia (он же рендер из google chrome) весьма неплох, даже по меркам авторов resvg - https://github.com/RazrFalcon/resvg?tab=readme-ov-file#svg-support
librsvg? Принципиально не буду ее добавлять, потому что нехер создавать людям столько трудностей в попытке иметь базовую систему без Rust!
Вот, раз уж добавил в репозиторий skia (https://t.iss.one/itpgchannel/2035), то было грех не запилить +1 рендер иконок, уже с ее помощью:
https://github.com/pg83/ix/blob/main/pkgs/bin/skia/svg/ss.cpp - это сама тулза, которая рендерит svg через #skia.
https://github.com/pg83/ix/tree/main/pkgs/bld/iconker - заодно похвастаюсь, сколько у меня вообще сейчас способов отрисовать svg иконку - через inkscape, через #lunasvg, через resvg (библиотека на Rust, лучше, чем librsvg, https://github.com/RazrFalcon/resvg), теперь вот через skia, ну и через #svgren.
Рендер через skia (он же рендер из google chrome) весьма неплох, даже по меркам авторов resvg - https://github.com/RazrFalcon/resvg?tab=readme-ov-file#svg-support
librsvg? Принципиально не буду ее добавлять, потому что нехер создавать людям столько трудностей в попытке иметь базовую систему без Rust!
GitHub
ix/pkgs/bin/skia/svg/ss.cpp at main · pg83/ix
ix package manager. Contribute to pg83/ix development by creating an account on GitHub.
🤡7🐳6👍3❤1
https://www.phoronix.com/news/Rust-Debian-2025
"around 8% of the source packages in Debian Sid are building against at least one librust-* package. That 8% figure for Debian source packages building against at least one Rust library package is around double of what it is for Debian 12 "Bookworm". Quite a significant uptake over the past few years and it's only continuing to grow with more open-source projects introducing varying levels of Rust integration"
Понятное дело, что это librsvg, или какие-нить кодеки, которые не являются обязательными, но против них нужно собраться, чтобы получить "полный" пакет, но, тем не менее, цифра довольно внушительная.
У меня против Rust собирается ровно 0 от базовой системы, потому что librsvg для загрузки иконок в gtk я переписал на кастомный #svg loader over #lunasvg/#skia/#svgren (по выбору), и убрал все эти опциональные зависимости.
Ну просто потому, что Rust не является #bootstrap абельным (я не могу собрать его из исходников, не имея под рукой готовый компилятор Rust, подробности в моей эпопее с #mrustc), а это зашквар.
"around 8% of the source packages in Debian Sid are building against at least one librust-* package. That 8% figure for Debian source packages building against at least one Rust library package is around double of what it is for Debian 12 "Bookworm". Quite a significant uptake over the past few years and it's only continuing to grow with more open-source projects introducing varying levels of Rust integration"
Понятное дело, что это librsvg, или какие-нить кодеки, которые не являются обязательными, но против них нужно собраться, чтобы получить "полный" пакет, но, тем не менее, цифра довольно внушительная.
У меня против Rust собирается ровно 0 от базовой системы, потому что librsvg для загрузки иконок в gtk я переписал на кастомный #svg loader over #lunasvg/#skia/#svgren (по выбору), и убрал все эти опциональные зависимости.
Ну просто потому, что Rust не является #bootstrap абельным (я не могу собрать его из исходников, не имея под рукой готовый компилятор Rust, подробности в моей эпопее с #mrustc), а это зашквар.
Phoronix
Around 8% Of Debian Source Packages Are Building Against Rust Libraries
At last week's DebConf25 Debian developer conference in France, Rust packaging within Debian Linux was talked about by Fabian Grünbichler
🤡8🔥5❤4👍3😁2💯1