Comments 34
Из графиков не понятна целесообразность — судя по графику JQuery в PNG занимает что-то межу 50 и 60 КБ, а gzip судя по closure-compiler.appspot.com/home должен занимать 32КБ
+22
Забавно, поучительно. Зануда mode on: практически все js, css и html и другие легко сжимаемые файлы отдаются с сервера уже сжатыми. То есть в настоящий момент нет необходимости даже минифицировать js и css, достаточно только комментарии вырезать. Даже не могу сообразить где ваш код пригодился бы.
+10
Согласен. Годится, по большому счету, лишь для забавы.
+3
Я бы написал об этом в статье, потому что мне показалось, что описанный в статье метод предлагается как решение проблемы сжатия скриптов.
Очевидно, что он не самый лучший, ведь есть gzip, который:
— поддерживается всеми браузерами
— поддерживается всеми серверами
— лучше сжимает
А идея сама очень прикольная, респект
Очевидно, что он не самый лучший, ведь есть gzip, который:
— поддерживается всеми браузерами
— поддерживается всеми серверами
— лучше сжимает
А идея сама очень прикольная, респект
+3
Если хочется совсем уж адского сжатия, то таки минифицировать желательно. Удаляются лишние пробелы, переводы строк и прочие штуки.
+1
просто для истории :) – Compression using Canvas and PNG-embedded data, May 4, 2008
+5
Я, грубо говоря, изобрёл велосипед
+3
Заместо прочтения статьи играл в марио.
+18
да-да, здесь и перевод :)
webo.in/articles/habrahabr/47-compression-using-canvas/
webo.in/articles/habrahabr/47-compression-using-canvas/
0
Напомнило habrahabr.ru/post/151538/
0
Когда реализовывал такую систему (вынужденно, т.к. требовалось залить интерактивный рассказ на Самиздат, а засунуть туда JS можно только через img-эксплойт), столкнулся с её ненадёжностью.
Во-первых, картинки частенько не прогружаются или прогружаются не полностью, особенно на мобильных устройствах с хреновым GPRS. Поэтому пришлось к изображению добавить контрольный столбец — самый правый столбик у меня содержал только синие (0,0,255) пиксели. Тогда перед декодированием можно проверить, прогрузилась ли картинка до конца или браузер срезал половину.
Во-вторых, браузеры на движке WebKit отличаются редкостной параноидальностью, и когда пользователь сохраняет страничку, то JS запущенной локальной копии не имеет доступа к данным канваса (кто только придумал такое ограничение?).
Наконец, оказалось, что слишком большие (>5Мб) картинки в процессе декодирования крашат Firefox for Android, причём он не просто падает, а уводит весь девайс в перезагрузку.
Во-первых, картинки частенько не прогружаются или прогружаются не полностью, особенно на мобильных устройствах с хреновым GPRS. Поэтому пришлось к изображению добавить контрольный столбец — самый правый столбик у меня содержал только синие (0,0,255) пиксели. Тогда перед декодированием можно проверить, прогрузилась ли картинка до конца или браузер срезал половину.
Во-вторых, браузеры на движке WebKit отличаются редкостной параноидальностью, и когда пользователь сохраняет страничку, то JS запущенной локальной копии не имеет доступа к данным канваса (кто только придумал такое ограничение?).
Наконец, оказалось, что слишком большие (>5Мб) картинки в процессе декодирования крашат Firefox for Android, причём он не просто падает, а уводит весь девайс в перезагрузку.
+20
Кстати, был опыт с Opera Turbo? Подозреваю, что пережатые картинки работать не будут вообще :)
+2
Сделал в Gimp PNG'шку размером 2000x2000 и объёмом 7.8 МБайт с RGB-шумом, попробовал открыть на Nexus 7 с Android 4.3:
Firefox 26.0.1: открыл, можно смотреть, масштабировать, полёт нормальный
Chrome 31.0.1650.59: упал
Разумеется, это ни о чём не говорит, просто интересный факт.
Firefox 26.0.1: открыл, можно смотреть, масштабировать, полёт нормальный
Chrome 31.0.1650.59: упал
Разумеется, это ни о чём не говорит, просто интересный факт.
+1
Да-да-да, я то же самое однажды сделал, но на Хабр поленился запостить.
Ссылка: animuchan.net/sukijs/ (см. исходники)
Ссылка: animuchan.net/sukijs/ (см. исходники)
+2
Было уже: habrahabr.ru/post/102394/ и habrahabr.ru/post/31607/
Техника старая, обсосанная не раз. Используйте браузерный gzip и не парьтесь.
Техника старая, обсосанная не раз. Используйте браузерный gzip и не парьтесь.
+1
Парень, ты ненормальный. В хорошем смысле слова :) Именно такие и двигаю прогресс в программировании.
+2
А что на счет использования данного способа для обфускации js? Столкнулся недавно с этой проблемой и кроме как closure и обфускаторы вида !([]+[])+[], которые увеличивают длину кода в 100500 раз и прекрасно деобфусцируются одним нажатием кнопки, ничего не нашел.
+1
Если я не ошибаюсь — в один пиксель можно загнать четыре байта? Альфа канал же ещё…
0
Всё верно, ARGB, по байту на канал. Жаль, что в статье не описано почему именно 3 байта берётся.
0
Сжимается плохо, да и альфа полбайта только, если не ошибаюсь.
0
Нельзя. К сожалению, canvas по-идиотски работает с альфа-каналом — в буфере хранятся не истинные цвета, а умноженные на значение альфа. В момент считывания браузер пытается восстановить их делением на альфа, что невозможно без потерь. Т.е. при считывании данных с канваса получим искажение цветов, если есть альфа-канал с переменными значениями.
+2
Что-то я такого не наблюдал. Возвращаются все 4 компоненты из канваса. В псевдомассиве data данные лежат как RGBA.
0
Данные возвращаются, но с потерей точности, т.е. эти RGBA будут немного (незаметно для глаза) отличаться от исходных.
Попробуйте закодировать текст в RGBA, засунуть этот массив в канвас, а потом сразу же снова считать и декодировать. При этом значительная часть символов заменяется «мусором» в результате потери точности.
Попробуйте закодировать текст в RGBA, засунуть этот массив в канвас, а потом сразу же снова считать и декодировать. При этом значительная часть символов заменяется «мусором» в результате потери точности.
0
Сурово и бесполезно на практике, но очень интересно. Спасибо за статью!
+2
А как насчет времени обработки js файлов с таким сжатием?
0
Полезного вынес из статьи то, что EmberJS точно не буду использовать в обозримом будущем)
+1
Sign up to leave a comment.
Portable Network Javascript