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