Доступен новый выпуск программы svgcleaner (https://github.com/RazrFalcon/svgcleaner), предназначенной для пакетной очистки SVG-файлов от ненужной информации. Чистка осуществляется без потерь для видимого изображения. По сути программа делает две вещи: удаляет элементы и атрибуты, не участвующие в конечном изображении, и приводит задействованные элементы и атрибуты к более компактному виду. В итоге, результирующий размер файла может быть уменьшен на 40-60%.
Код программы написан на Rust и распространяется (https://github.com/RazrFalcon/svgcleaner) под лицензией GPLv2. Для управления процессом очистки отдельно подготовлен графический интерфейс (https://github.com/RazrFalcon/svgcleaner-gui) на Qt. Готовые сборки доступны (https://github.com/RazrFalcon/svgcleaner-gui/releases) для Linux x86_64 (portable-архив), Windows и macOS.
Основные изменения:
- Консольная версия переписана с C++ на Rust.
- Реализованы собственные библиотеки для разбора SVG и представления SVG в виде DOM.
- Существенное увеличение производительности, программа стала работать в 3 раза быстрее.
- Все функции очистки теперь работают в режиме без потерь качества (lossless).
- Степень очистки снижена на ~5%, ценой стабильности и корректности;
- Добавлена документация (https://github.com/RazrFalcon/svgcleaner/blob/master/docs/sv...) для каждой опции очистки.
- GUI переписан с нуля и вынесен в отдельный репозиторий (https://github.com/RazrFalcon/svgcleaner-gui).URL: https://github.com/RazrFalcon/svgcleaner
Новость: http://www.opennet.me/opennews/art.shtml?num=45297
Какой-то велосипед.
Время с точностью до 0.00001 секунды - это круто
С каких это пор для компьютеров интервалы времени в 0.01 миллисекунду стали чем-то мелким и не заслуживающим измерения? Даже в начале 90-х время работы процессов всегда мерялось в долях миллисекунды, а иногда и в микросекундах.
Ты метрологическую проверку сделал, что автор программы измеряет что надо?
Пользователю это не надо, и QElapsedTimer не даёт гарантированную точность на полных разрядах своего типа данных.
К чему твоё высказывание?
Может всё-таки "поверка"?
Пора бы уже заметить и усвоить эту разницу в одну букву.
У обычных писюков 10 микросекунд могут работать а могут и нет. Это как минимум требует таймер высокого разрешения (>=100 kHz).
А какая вообще разница сколько там миллисекунд затрачено на очистку этого файла, особенно если ты делаешь это вручную через GUI?
Ну так среднее время очистки в районе 10мс. В чем тогда мерять?
Вот в миллисекундах и мерять. Там флуктуации доступа к диску или особенности шедулера больше повлияют, чем эти доли.
Можно и без дробной части, да. Это не принципиально. Просто есть файлы которые обрабатываются меньше чем за 1мс.
А зачем вообще мерить?
Это философский вопрос. Особой нужды нет.
> Это философский вопрос. Особой нужды нет.Ответ на него давно дал Кнут, сказавший что преждевременная оптимизация - корень всех зол.
Да, совершенно верно. И поэтому автор svgcleaner пишет на опеннете новости о своей программе, а Аноним перечитавший Кнута изображает иксперда в комментах к этой новости.Во-первых, не надо путать оптимизацию, и диагностику производительности.
Во-вторых, дай себе труд повтыкать вот сюда: https://gist.github.com/hellerbarde/2843375
Ты видишь, что среди разных рассмотренных временных отрезков младшие пять _порядков_ на глаз неразличимы? То есть, при определённых условиях, можно, совершив какую-нибудь глупость, сделать свою программу раз в сто тормознее и даже не заметить этого. Двадцать лет назад, и тем более до этого, такой проблемы не было, потому что "программа в сто раз медленнее" -- это было практически наверняка заметно глазом. Сегодня программист накручивает одну сложность на другую сложность, на третью, на десятую, программа начинает выполняться уже не "моментально", а всего лишь "в мгновение ока". Программу отправляют на "боевую задачу", где объёмы выполняемой работы на пару порядков больше, и выясняется что программа говно. И оптимизировать её уже невозможно, потому что там накрученных сложностей и алгоритмических глупостей больше, чем собственно кода.
И я попрошу заметить ещё один факт: Кнут писал TAOCP, работая на столь древних и тормозных компьютерах, которые ни тебе, ни даже мне не пришлось застать. И на тех компьютерах оптимизация становилась своевременной и даже необходимой после первой же глупости, типа выбора списка с простыми инсёртами, вместо массива с простым рандом-акцессом.
Чем она преждевременная? Прога зарелизена уже. Оптимизируй - не хочу.
Для оптимизации процесса. Для опеннетчиков же это философские вопросы и поводы покудахтать.
Допустим:
1.есть 10 тыс файлов.
2.Их надо пройти этим софтом.
Зная среднее время можно хоть примерно сказать сколько времени необходимо на все 10 тыс.
Не?
неа. файлы могут быть сильно разными, не угадаешь.
Можно смотреть по общему объёму, там основная работа идёт построчная.
>>основная работа идёт построчнаяНикакой работы со строками тут нет.
>>>основная работа идёт построчная
> Никакой работы со строками тут нет.А как он тогда работает с xml(svg)?
Посредством генерации DOM.
А домик из воздуха строят. Ну-ну.
Файл может читаться блочно, а не построчно.
О, для Rust уже есть Qt-биндинг.>Консольная версия переписана с C++ на Rust.
Ну это поспешили, в GCC ещё нет фронтенда для Rust.
Нет. GUI на С++.>>в GCC ещё нет фронтенда для Rust.
И это прекрасно.
А что, биндинг для Rust на Qt не написал?
> И это прекрасно.Хороший повод не пользоваться такими программами, чтобы когда мозилла околеет - не пойти на дно вместе с их стремной экосистемой и такими аффтарами.
>> И это прекрасно.
> Хороший повод не пользоваться такими программами, чтобы когда мозилла околеет - не
> пойти на дно вместе с их стремной экосистемой и такими аффтарами.Можно подумать, анонима заставляют платить за пользование программой -- и таким образом хотят развести на бабло. А компилятор с экосистемой закрытая проприетарь и сразу сломается.
Уважаемый форточник (или маковод), вы кое-что путаете -- это совсем не то, к чему вы так привыкли!
Хорошая программа, с её помощью в KDE оптимизировали иконки Breeze, размер уменьшился с 28,0 до 9,4 мегабайт.Непонятно только, зачем понадобилось переписывать на (гораздо менее популярный и, как уже сказали, ещё отсутствующий в GCC) Rust. Автор хочет сказать, что ускорение в три раза получилось сменой языка, а не модернизацией алгоритма? Прошу ответить конструктивно. :)
Кому (которому из присутствующих здесь анонимов) адресован вопрос?
Они использовали svgo, насколько я знаю. И то, у них там от силы половина файлов обработана. svgcleaner позволяет еще в 2 раза сжать.
https://kdeonlinux.wordpress.com/2016/04/25/performance-upda.../
Тем временем: https://github.com/KDE/breeze-icons/blob/master/optimize-svg.sh
Сжать после SVGO в 2 раза :) ?
Те иконки, что лежат у них в репе, можно сжать в два раза. Если они и прогоняют их через svgo, то на очень слабых настройках.
Увеличение производительности связано исключительно с алгоритмами. Rust даже немного медленнее плюсов.Но так как это личный проект - пишу на том, на чём удобно. А это Rust. От плюсов слишком много боли.
боль лишь у неосиляторов стандарта и у мазохистов с кривыми компиляторами
Не знаю, как у автора, а у меня бывало, что переписывание нетривиального алгоритма с C-like оптимизированной версии на обычные STL-контейнеры заметно ускорило алгоритм просто потому, что автор стал лучше понимать, что конкретно происходит в процессе ;)Здесь же стоит учесть, что SVG - это, в сущности, XML. Если разбирать (а потом писать) его своим велосипедом на "крестах", может здорово просесть производительность по сравнению со стандартной, оптимизированной по скорости библиотекой высокоуровневого языка. Впрочем, никто не мешает подобрать аналогичную библиотеку и для "крестов"...
> Не знаю, как у автора, а у меня бывало ... что автор стал лучше понимать...Как это понимать?
Может быть, после второго-третьего прочтения?Ничего сложного вроде бы не написано и довольно очевидно, что в первом случае имеется в виду автор обсуждаемой программы, а во втором - автор вышеупомянутого алгоритма.
Использование одного и того же слова сломало парсинг? Сочувствую...
Ты напрасно называешь себя автором алгоритма - у тебя не то что не отросли навыки алгоритмического мышления, но и отсутствует культура написания вменяемого кода.
Именование переменных, понимание их области видимости - всё это в лучшем случае у тебя впереди.
Дерзай.
многопоточность
Программа однопоточная. GUI просто запускает несколько копий параллельно. Но увеличение производительности именно в консольной версии, которая однопоточная.
Столбец Ratio странный. Либо там должно быть отношение размеров стало/было, либо он должен называться «Удалено». Тогда будет понятно. А сейчас не понятно.
левее 2 столбца «стало» и «было»
Я вижу. Но проценты вычисляются так: (1 - стало/было) * 100. Не совсем Ratio, правда? Это число показывает сколько процентов байт было удалено.
Столбец показывает сколько было удалено. С терминологией, возможно, неувязка.
"Size reduction"
А для видеофайлов такое есть? В информации о файлах, озданных мной, всегда libavcodec 57
> Степень очистки снижена на ~5%, ценой стабильности и корректности;Какой из следующих вариантов означает эта фраза?
чистить стало хуже, зато стабильнее и корректнее
чистить стало лучше, зато менее стабильно и корректно
чистить стало хуже, зато менее стабильно и корректно
Первый.
"теперь работают в режиме без потерь качества (lossless)" - значит ранее описанную словом линию (векторная графика ведь) изгибали или уничтожали? Или этот тег писали через букву?
Суть в том, что раньше программа содержала деструктивные опции, которые удаляли/искажали видимые части изображения. Теперь их нет.
► Спасибо за полезный ответ !
$ cargo build --release --verbose
Fresh bitflags v0.7.0
Fresh unicode-segmentation v0.1.2
Fresh phf_shared v0.7.17
Fresh unicode-width v0.1.3
Fresh vec_map v0.6.0
Fresh phf v0.7.17
Compiling clap v2.14.0
Running `rustc /home/rus/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.14.0/src/lib.rs --crate-name clap --crate-type lib -C opt-level=3 -C metadata=47d4e23f711b933e -C extra-filename=-47d4e23f711b933e --out-dir /home/rus/src/svgcleaner/target/release/deps --emit=dep-info,link -L dependency=/home/rus/src/svgcleaner/target/release/deps -L dependency=/home/rus/src/svgcleaner/target/release/deps --extern bitflags=/home/rus/src/svgcleaner/target/release/deps/libbitflags-2dd0c81d457fcc54.rlib --extern vec_map=/home/rus/src/svgcleaner/target/release/deps/libvec_map-9d6bd4d086585cc9.rlib --extern unicode_width=/home/rus/src/svgcleaner/target/release/deps/libunicode_width-d37ed639dbcdab2f.rlib --extern unicode_segmentation=/home/rus/src/svgcleaner/target/release/deps/libunicode_segmentation-d37f6d231e3bd6a5.rlib --cap-lints allow`
Fresh svgparser v0.1.0
Compiling svgdom v0.1.0
Running `rustc /home/rus/.cargo/registry/src/github.com-1ecc6299db9ec823/svgdom-0.1.0/src/lib.rs --crate-name svgdom --crate-type lib -C opt-level=3 -C metadata=17b1a97db8c70920 -C extra-filename=-17b1a97db8c70920 --out-dir /home/rus/src/svgcleaner/target/release/deps --emit=dep-info,link -L dependency=/home/rus/src/svgcleaner/target/release/deps -L dependency=/home/rus/src/svgcleaner/target/release/deps --extern svgparser=/home/rus/src/svgcleaner/target/release/deps/libsvgparser-32810ae35a86d6dd.rlib --cap-lints allow`
/home/rus/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.14.0/src/errors.rs:857:35: 857:46 error: no method named `description` found for type `std::fmt::Error` in the current scope
/home/rus/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.14.0/src/errors.rs:857 Error::with_description(e.description(), ErrorKind::Format)
^~~~~~~~~~~
error: aborting due to previous error
Build failed, waiting for other jobs to finish...
error: Could not compile `clap`.Caused by:
Process didn't exit successfully: `rustc /home/rus/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.14.0/src/lib.rs --crate-name clap --crate-type lib -C opt-level=3 -C metadata=47d4e23f711b933e -C extra-filename=-47d4e23f711b933e --out-dir /home/rus/src/svgcleaner/target/release/deps --emit=dep-info,link -L dependency=/home/rus/src/svgcleaner/target/release/deps -L dependency=/home/rus/src/svgcleaner/target/release/deps --extern bitflags=/home/rus/src/svgcleaner/target/release/deps/libbitflags-2dd0c81d457fcc54.rlib --extern vec_map=/home/rus/src/svgcleaner/target/release/deps/libvec_map-9d6bd4d086585cc9.rlib --extern unicode_width=/home/rus/src/svgcleaner/target/release/deps/libunicode_width-d37ed639dbcdab2f.rlib --extern unicode_segmentation=/home/rus/src/svgcleaner/target/release/deps/libunicode_segmentation-d37f6d231e3bd6a5.rlib --cap-lints allow` (exit code: 101)
Что делать?$ cargo --version
cargo 0.11.0 (built 2016-08-21)$ rustc --version
rustc 1.10.0
Мда. Я думал что у GCC в C++ плохие сообщения об ошибках. Признаю, был неправ!
Писать багрепорт в https://github.com/kbknapp/clap-rs, ибо это его ошибка. Для начала советую обновить Rust до последней версии. В Readme указано, что нужна последняя стабильная версия.
Пропустил через svgcleaner файл сделанный в Inkscape.
Исходный файл: 42мб, имеет много слоёв с векторами и битмапами, многие слои временно выключены.
Файл на выходе: 10мб, информация о слоях удалена, невидимые элементы удалены.
Впечатления:
- gui-версия из Downloads не запускается "...could not find or load the Qt platform plugin "xcb""
- консольная версия работает
- считаю, что фраза "losslessly reduce size" из описания программы вводит в заблуждение.
- эдакий "Flatten Image" for publishing svg-files
> - считаю, что фраза "losslessly reduce size" из описания программы вводит в заблуждение.Вообще-то когда говорится о потере качества в векторной графике - обычно имеется в виду огрубление линий путем уменьшения количества узлов и упрощение эффектов - например, их растеризацией. В данном случае ни того, ни другого не происходит, качество картинки не теряется - так что имеет место тот самый заявленный lossless reduce.
Теряется дополнительная информация - так это и является заявленным функционалом программы! Она и предназначена для постпродакшена, а не для рабочих файлов. Ну, и полей для откровенно ненужной информации в этом формате не предусмотрено ;)
> - gui-версия из Downloads не запускается "...could not find or load the
> Qt platform plugin "xcb""Это на LOR уже разрешили. Надо пакет libxcb-xinerama0 доставить там, где его нет (на Mint или Федорке).
https://www.linux.org.ru/news/opensource/12935157?cid=12935965
Ниже по треду проблему с падением 7za тоже решили.
>>информация о слоях удаленаВ SVG нет понятия Слой. Inkscape просто создаёт группу, которую svgcleaner с легкостью удаляет, ибо она не имеет смысла. "Отключенные слои" - это просто <g display="none">, вот я его и удаляю.
Вы можете отключить: Ungroup groups и Remove invisible elements, что бы оставить "слои".
>>считаю, что фраза "losslessly reduce size" из описания программы вводит в заблуждение.
В README чётко описано зачем нужна прога: "The main purpose of the svgcleaner is to losslessly reduce size of an SVG image, created in a vector editing application, before publishing.". То есть чистить "рабочий" файл смысла нет.
> Консольная версия переписана с C++ на Rust.
> Существенное увеличение производительности (до трёх раз быстрее)Отсюда следует вывод, что Rust быстрее C++ в 3 раза. Это вправду так?
https://www.opennet.me/openforum/vsluhforumID3/109350.html#18