svgcleaner 0.7.0

-mtune=generic при сборке?

Вы о 7z? Там самописные мейкфайлы. Нужно попробовать.

Ага. Ну может он умеет в CFLAGS какой.

Компилятор же для него весит около 450 Мб.

pkg info -s rust
rust-1.12.0                    258MiB

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

Нода всегда и была консольной, глупенький.

Попробуйте запустить этот 7za: https://dl.dropboxusercontent.com/u/16019144/7za

Не должен выдавать ошибки. Если всё ок - то буду его распространять.

PS: никаких руткитов там нет, если вы не параноик, просто пересобрал с -mtune=generic.

Смешной код нам не нужен, сорь.

Уходи.

Падает.
Исследовал немного, падает из-за того, что CPU AVX не поддерживает. Падает на инструкции vzeroupper. ЕМНИП в gcc -mno-avx это отключает. По крайней мере, в p7zip, видимо, собрано без AVX-оптимизации.

Магия. Уже всё поотключал, а толку 0.

buddhist собираю с -march=core2 -static -mno-sse3 -mno-ssse3, а в objdump всё равно лежат sse3 инструкции. Не в курсе в чём прикол?

А если другую архитектуру задать?

Пробовал generic, как вы и советовали, - тоже самое. Или p7zip сам использует sse, или я хз. Как минимум с -mno-sse2 он собираться отказался.

tune=generic? arch=generic не существует. Можно еще arch=i386 какой-нибудь, но это немного извращенно.

Да, tune.

Нет, ибо lossless.

Это типо религия такая? Как например чистота ФП. Почему нельзя оставить разъём под lossy плагины для практических нужд (в расте наверно проблемы с динамической загрузкой плагинов, да)? Групповые трансформации кстати - отдельное поле для возможных оптимизаций. И почему нельзя применить трансформацию к самим координатам (ну может быть частично в случае если там квадрат вращается например) и округлять уже в правильном масштабе. Да и вообще округление нужно для фигур, нарисованных руками, там маловероятно встретить скалирование в 1000 раз. Так что можно просто проверить матрицу трансформации, уместно ли округление тут.

Минимальный набор инструкций для 64-битного x86 дает arch=athlon64, но проц по ссылке SkyMaverick поддерживает все вплоть до SSE4.2. Но в вашем бинаре есть AVX инструкции в том числе.

В этом и прикол. Не могу понять почему 7z игнорирует настройки.

Сегодня одно, завтра другое, послезавтра комбайн.

Групповые трансформации кстати

Что вы под этим подразумеваете?

округлять уже в правильном масштабе

Потому, что нужно реализовать расчёт реальных координат для всех элементов. Это не так просто.

округление нужно для фигур

У меня на тестах, при точности в 2-3 знака, половина файлов убивается. Даже не стал разбираться.

Так что можно просто проверить матрицу трансформации, уместно ли округление тут.

Поэтому там и сказано, что как только разберусь как это сделать без потерь - сделаю. Сейчас это не реализовано.

-march=core2 и -mno-sse3 — противоречащие друг другу настройки и, ЕМНИП, arch всегда приоритетнее. Мне кажется, что с бинарем, собранным с -march=core2, у SkyMaverick проблем быть не должно

Попробуем.

SkyMaverick попробуйте эту сборку: https://dl.dropboxusercontent.com/u/16019144/7za

Попробовал. Без изменений. Ну, кроме ip инструкции. Действительно магия какая-то.
С ссылкой работает.

Понятно. Спасибо.

Добавлю readme с подсказкой, что можно симлинк сделать.

RazrFalcon

Странно, там до сих пор остались AVX-инструкции. Вечером доберусь до убогой тачки с линуксом (древний атом), попробую собрать.

Групповые трансформации

Ну короче собирать подобные трансформы элементов в трансформ группы из этих элементов добиваясь более короткой записи трансформов ну или даже более коротких записей координат (ну типа вынести сдвиг на 0.0001 из кучи чисел вида <x>.0001 «за скобки»).

А да, упрощение путей оно умеет? Конечно в общем случае надо бы lossy упрощение но хотя бы в случаях когда 2 соседних примитива можно математически точно слить в один.

в расте наверно проблемы с динамической загрузкой плагинов, да)?

По идее, нет.

Ну с ансейфами каждый дурак сможет. А как подгрузить сразу реализацию растового трейта чи как там в расте наследник класса сделан?

А как подгрузить сразу реализацию растового трейта чи как там в расте наследник класса сделан?

Дык, что помешает возвращать из библиотеки указатель на трейт? Но unsafe всё равно останется.

SkyMaverick

http://rgho.st/8mp55bXqb — собрал, вроде крутых инструкций быть не должно. Если вы, конечно, доверяете бинарю от рандомного лоровца :)

«Урррааа заработало» (с) скрин

Если вы, конечно, доверяете бинарю от рандомного лоровца

Ну я не параноик :) К тому же для благого дела.
ЗЫ. А в чём была загвоздка со сборкой, если не секрет?

Дык, что помешает возвращать из библиотеки указатель на трейт?

Хм, а разная версия компилятора не помешает? И вообще оно сможет кастануть из void*? А то помню в кристале были реальные проблемы с тем, чтоб кастануть полиморфный указатель в void* и потом обратно - указатель терял динамический тип и вызывал методы базового класса. Собственно в расте вроде как тоже закос в мономорфность, так что могут быть проблемы. Ну если вместо таблицы вирт функций, встроенной в сам объект используется отдельный указатель на нее, автоматически подставляемый компилятором, но никак не сохраняющийся при касте объекта в void*.

Каким образом?

Понял. Такого нет. Обычно это будет длиннее чем координаты:

100 100 100 100 100 100 100 100
0 0 0 0 0 0 0 0 transform="translate(100 100)"

Намного проще как раз применять трансформации, а не выносить. Но частичный «вынос» тоже будет.

Да. Пока в базом виде: https://github.com/RazrFalcon/svgcleaner/blob/master/docs/svgcleaner.rst#paths

https://github.com/RazrFalcon/svgcleaner#alternatives как-то очень поверхностно сравнивается.

И там какие-то стрёмные заявления про беспотерьность. Если про то, что нет фичи округления точности коодинат - это какое-то сомнительное преимущество. И если ничего не путаю, то SVGO по дефолту оптимизирует без потерь.

В goals тоже слегка абстрактно, «дальше, выше, сильнее». Ни о чем.

Я ничего против проекта не имею. Просто с точки зрения человека, который пользовался SVGO, не совсем понятно нафик это надо. Возможно есть какие-то интересности, но они не донесены.

А, нашел графики. Довольно симпатично получается.

Могу еще преложить тесты отсюда https://github.com/fontello/svgpath/tree/master/test глянуть. Приходилось со всякими косяками сталкиваться на трансформациях арок и т.п. В SVGO кстати у арок есть проблемы.

не совсем понятно нафик это надо

График Correctness ни о чём не говорит? svgo ни разу не lossless. Плюс у него много ошибок.

И там какие-то стрёмные заявления про беспотерьность

Что там не понятно?

И если ничего не путаю, то SVGO по дефолту оптимизирует без потерь.

Нет.

В goals тоже слегка абстрактно, «дальше, выше, сильнее». Ни о чем.

Предложите лучше.

https://github.com/fontello/svgpath/tree/master/test

Не вижу там svg файлов. Выдирать тесты из api.js муторно, и там не совсем то, что делает прога. С парсингом путей у меня проблем нет.

У меня еще осталось 3000 файлов-тестов от вебкита. Вот там настоящий ад.

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

Что там не понятно?

Слова там понятны, но не очень понятно зачем это надо юзеру. Например, округление координат до целых довольно прилично сокращает размер (точка + как минимум еще 1 знак после). Какой смысл лишать юзера подобной возможности если он знает что делает? Если картинки 1000х1000, там целых обычно достаточно.

Про скорость - круто конечно. Но мне трудно представить проекты, где надо тонны картинок постоянно оптимизировать.

Например, округление координат до целых довольно прилично сокращает размер

Нет. Сейчас используется округление до 8 знаков после запятой. Уменьшение до 6 даёт прирос от силы в пол процента. До 3 - пару процентов, при условии, что половину файлов корежит. У меня даже с точностью в 8 знаков куча артефактов, а вы про 1 знак после запятой. Не смешите.

Но мне трудно представить проекты, где надо тонны картинок постоянно оптимизировать.

Паки иконок? Тем более разница почти в 100 раз - это не шутки. Мне интересно выжать макс. производительность. Вам не нужно - проходите мимо.

он знает что делает

Обычно не знает. Если так хочется - пусть руками чистит. Производительно то всё равно не важна вам.

Не смешите.

Рад что вас повеселил. Это однако не меняет факта, что на монохромных картинках, состоящих только из path, разница в размерах гораздо больше, чем вы говорите.

Паки иконок? Тем более разница почти в 100 раз - это не шутки. Мне интересно выжать макс. производительность. Вам не нужно - проходите мимо.

Хосспадя... примите разупорин уже. Вы спросили, что именно непонятно. Я просто ответил на ваш вопрос.

Это однако не меняет факта, что на монохромных картинках, состоящих только из path, разница в размерах гораздо больше, чем вы говорите.

В FAQ чётко указано, что как только я найду способ как статически доказать неизменность изображения - я добавлю эту фичу.

Хосспадя... примите разупорин уже.

Наезжаете на мой проект даже не дочитав ридми, а я потом еще и крайний.

SkyMaverick

Собрал с arch=athlon64, tune=generic и все нормально стало.

В FAQ чётко указано, что как только я найду способ как статически доказать неизменность изображения - я добавлю эту фичу.

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

Можно даже картинку 10х10 менять на 1000х1000 + scale(0.01), чтобы от плавучки в остальных местах избавиться.

вспомнил сисиклинер, пкклинер и прочий подобный шлак. вздрогнул )

Любое округление. Там лишь пример.

К примеру: имеем длину в 0.001in, при определенных dpi это будет не таким уж маленьким значением.

Так же есть куча проблем с путями. К примеру задание окружности через один ArcTo путём расположения двух координат очень близко друг к другу, но не совпадающих. Малейшее округление, даже до 5-6 знаков, приведёт к совпадению координат и пропаже окружностей. В старой версии даже был костыль, который пропускал округление ArcTo.

Малейшее округление stdDeviation приводит к искажению размытия. Даже текущих 8-и знаков после запятой не хватает.

И я могу продолжать бесконечно.

Повторюсь: если округление и будет реализовано, то не глобальное, а отдельное для разных видов значений.

Ну естественно надо округлять не всё под одну гребенку. У тех же арок с радиусами надо обходиться аккуратнее. А так на фонтелле пути постоянно округляются, и с проблемами никто не прибегает.

Ну так вот такого округления пока нет. На шрифта может не так заметно. Когда у нас путь рендерится на холст 1000х1000 - разница может быть ощутимая.

Вот пример проблемы: https://github.com/RazrFalcon/svgcleaner/blob/master/docs/testing_notes.rst#a...