Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Спасибо за статью, примерно так и хотел поступить. Теперь не придётся на себе всё это испытывать.
Очень не хотелось ставить отдельно под этот эксперимент 12-ю версию. Не смотря на то, что она еще кое-кем используется, скоро и это число преданных поклонников вынуждено будет либо обновиться, либо мигрировать на другой браузер.
В стандартном установщике Opera 12 есть возможность поставить её переносную версию — быстро и без всякого внедрения в ОС.
Да и насчёт миграции — вопрос спорный. Достойной альтернативы в обозримом будущем не предвидится (не считая FF с расширениями — но он заметно медленнее), а комфортно обозревать интернет с помощью настоящей Opera можно будет ещё несколько лет. Так что рано ещё её списывать со счетов, по крайней мере в рунете.
Насчет достойной альтернативы — вопрос спорный. Да, в той самой Опере, возможно, есть некоторые фичи, которые Вам дороги. И в то же время с внедрением новых фич у остальных, 12-я версия все более безнадежно будет устаревать и в конце концов минусы перевесят плюсы.
Но ок, пока не буду списывать со счетов. По крайней мере мысленно :) Если будет время, попробую в ней прогнать.
Но ок, пока не буду списывать со счетов. По крайней мере мысленно :) Если будет время, попробую в ней прогнать.
Рано или поздно в новой Опере вернут и допилят старые фишки. Так что мы все будем довольны. Я как поклонник оперы с малых ногтей (ещё сижу на старой дома, но на новой в офисе), и я как веб-разработчик будем рады обрести вновь Нашу Прелесть.
Насчет альтернативы это вы зря.
Например:
Maxthon — самый достойный браузер с большинство фичей Opera реализовано идаже есть уникальные фичи. Работает на WebKit движке с возможностью переключения на Trident.
Реализованого функционала HTML5 Больше чем у хрома. HTML5TEST: Maxthon 4.2 — 515. Тогда ка у ХРОМА 31 — 503, Opera 18 — 494, FF26 — 446.
По скорости не намного отстает от Chroma. 2708 против 3015 по peacekeeper.futuremark.com. И намного быстрее Ослика 11 (1719 мирный попугай). И совсем чуть чуть медленней Opera 18 (2878 попугаев).
Например:
Maxthon — самый достойный браузер с большинство фичей Opera реализовано идаже есть уникальные фичи. Работает на WebKit движке с возможностью переключения на Trident.
Реализованого функционала HTML5 Больше чем у хрома. HTML5TEST: Maxthon 4.2 — 515. Тогда ка у ХРОМА 31 — 503, Opera 18 — 494, FF26 — 446.
По скорости не намного отстает от Chroma. 2708 против 3015 по peacekeeper.futuremark.com. И намного быстрее Ослика 11 (1719 мирный попугай). И совсем чуть чуть медленней Opera 18 (2878 попугаев).
Надеюсь, что созданные на клиенте превьюхи не записываются на сервере без доп. проверок/обработок и не показываются потом посетителям «как есть».
Конкретно в моем приложении они пока еще даже не отправляются на сервер :) Но, разумеется, и не планирую так делать. Тем более, мне не нравится как некоторые браузеры сглаживают уменьшенные таким образом изображения.
Скажу пару слов о том, какова конечная цель задуманного. Пользователю необходимо иметь возможность загружать сразу большие альбомы и подборки фотографий. При этом, закинув все фотографии из папки, он, возможно, захочет какие-то тут же убрать из списка. А некоторые, вероятно, сразу же повернуть. Если делать по старинке, т.е. грузить сразу после добавления на сервер, а в ответ получать ссылки на уже уменьшенные изображения, то а) серверу надо будет заниматься обработкой как можно скорее, и б) нужно проделывать лишнюю работу: удаление ненужных фотографий и осуществление поворота картинок. Теперь же, обработку можно отложить, но при этом пользователь будет моментально видеть результат (пусть и приблизительный). Плюс данные о повороте будут отправляться сразу с изображением и на сервере можно сразу же повернуть изображение как надо, параллельно с созданием превьюхи. Более того, я думаю пойти еще дальше и на клиенте считать md5 (или sha1) хеш изображения и предупреждать пользователя о вероятных дублях.
Скажу пару слов о том, какова конечная цель задуманного. Пользователю необходимо иметь возможность загружать сразу большие альбомы и подборки фотографий. При этом, закинув все фотографии из папки, он, возможно, захочет какие-то тут же убрать из списка. А некоторые, вероятно, сразу же повернуть. Если делать по старинке, т.е. грузить сразу после добавления на сервер, а в ответ получать ссылки на уже уменьшенные изображения, то а) серверу надо будет заниматься обработкой как можно скорее, и б) нужно проделывать лишнюю работу: удаление ненужных фотографий и осуществление поворота картинок. Теперь же, обработку можно отложить, но при этом пользователь будет моментально видеть результат (пусть и приблизительный). Плюс данные о повороте будут отправляться сразу с изображением и на сервере можно сразу же повернуть изображение как надо, параллельно с созданием превьюхи. Более того, я думаю пойти еще дальше и на клиенте считать md5 (или sha1) хеш изображения и предупреждать пользователя о вероятных дублях.
Я это на всякий случай написал, а то мало-ли кто забудет.
Многие фотики в exif пишут ориентацию фотки. Если она там есть, то надо сразу её использовать.
Многие фотики в exif пишут ориентацию фотки. Если она там есть, то надо сразу её использовать.
Кстати, интересно. Спасибо за инфо. Вот теперь придется еще и exif пытаться на клиенте расковыривать…
Если в фотошопе, лайтруме и т.п. редакторах правились фотки, то экзиф информация сотрется.
Не забудьте и это учесть:)
Не забудьте и это учесть:)
Ок. Ну а где-то ее и вовсе не будет изначально. Так что в любом случае — это опционально. А не знаете, кстати, готовых JS-библиотек?
Неа, не встречал.
В основном встречается что-то наподобие вот такого: github.com/blueimp/JavaScript-Load-Image
У Вас уже есть готовый функционал ресайза изображения, а добавить парсер exif-инфы дело техники.
Кстати, если будет время и желание, то можно оформить этот парсер в виде либы, залить на гитхаб, опубликовать решение на Хабре и Вы получите комментарии благодарности местных жителей:))
В основном встречается что-то наподобие вот такого: github.com/blueimp/JavaScript-Load-Image
У Вас уже есть готовый функционал ресайза изображения, а добавить парсер exif-инфы дело техники.
Кстати, если будет время и желание, то можно оформить этот парсер в виде либы, залить на гитхаб, опубликовать решение на Хабре и Вы получите комментарии благодарности местных жителей:))
Окей, договорились — если решусь реализовать это для своего проекта, то обязательно опубликую :)
Присмотрелся подробнее к библиотеке по ссылке. Хорошая библиотека. Думаю, нет смысла городить велосипед с собственным EXIF-парсером, там это уже есть
может вы смотрели, какие именно операции приводят к увеличению потребления памяти (выбор файлов в диалоговом окне, чтение в FileObject через readAsDataURI(), добавление картинки в DOM и т.п.)?
хочу понять, имеет-ли все это смысл, если оригиналы терять нельзя — например для последующей отправки их на сервер — и какую стратегию лучше выбрать.
хочу понять, имеет-ли все это смысл, если оригиналы терять нельзя — например для последующей отправки их на сервер — и какую стратегию лучше выбрать.
Смотрел. Имеет смысл. Вы можете сохранять где-то в массиве (или каком-то объекте, отображающем загрузку) исходные объекты типа File. Сами по себе они ничего практически не весят, но их можно приаттачивать к запросу, тем самым отправляя оригинал. Выбор файлов, естественно тоже ничего не жрет (еще бы вывод системного окошка требовал ресурсов! :), а от readAsDataURL нам удалось отказаться.
Понимаете, изначально вообще не было цели устраивать тесты браузеров. Цель была найти подход, позволяющий генерить превью для относительно больших картинок, не выходя за разумные рамки в плане использования памяти. Я сейчас пользуюсь Яндексом, поэтому все смотрю изначально в нем. Но при этом важно было понимать, что применяемые оптимизации проявляются не только в моем браузере, поэтому я стал параллельно проверять в остальных, установленных в системе. Можно было бы, наверное, и не включать Хром. Но тогда для многих выбор показался бы еще более странным :)
Если посмотреть на все это немного под другим углом, то выбор и не покажется таким уж странным: представлено три основных движка, при этом самый популярный из них в двух исполнениях.
P.S. По 12-й Опере добавил краткий UPD
Если посмотреть на все это немного под другим углом, то выбор и не покажется таким уж странным: представлено три основных движка, при этом самый популярный из них в двух исполнениях.
P.S. По 12-й Опере добавил краткий UPD
Как вы меряли потребляемую память? Уверен, это прольет свет на выдающийся результат IE.
В статье упоминается, что я попросту наблюдал за стандартным таск менеджером. Никаких других, более точных замеров не производил. А что, ИЕ куда-то «прячет» память?
Если колонка «Память» на вкладке Процессы, то это текущий рабочий набор процесса или процессов (кстати для Хрома суммировали?).
IE не прячет. Но имеет определенное преимущество: работу с памятью его разработчикам нужно оптимизировать только под одну ось. А минимизировать рабочий набор их там заставляют жестко. :)
Деталей я конечно не знаю, но могу предположить, что в других браузерах блоки памяти с освобожденными объектами сразу не используются повторно, а ждут, например, GC.
P.S. По теме, вот еще один свежий бенчмарк: www.ghacks.net/2014/01/02/chrome-34-firefox-29-internet-explorer-11-memory-use-2014/
IE не прячет. Но имеет определенное преимущество: работу с памятью его разработчикам нужно оптимизировать только под одну ось. А минимизировать рабочий набор их там заставляют жестко. :)
Деталей я конечно не знаю, но могу предположить, что в других браузерах блоки памяти с освобожденными объектами сразу не используются повторно, а ждут, например, GC.
P.S. По теме, вот еще один свежий бенчмарк: www.ghacks.net/2014/01/02/chrome-34-firefox-29-internet-explorer-11-memory-use-2014/
Спасибо за пояснения и ссылку.
Да, я смотрел именно в колонку «Память». Конечно, я понимаю, что использовать таск менеджер для серьезного исследования расхода памяти не стоит, но в контексте данной задачи этого было достаточно чтобы зафиксировать резкие возрастания ее расхода. Важно было скорее решить проблему, слишком глубоко не вдаваясь в причины ее возникновения.
Согласен, что ИЕ скорее всего более эффективно взаимодействует с родной ОСью и в этом у него есть преимущество (что характерно, подобным образом ведет себя и Сафари на маке — т.е. выглядит так, будто ему вообще не требуется никакой дополнительной памяти для этих операций).
Да, я смотрел именно в колонку «Память». Конечно, я понимаю, что использовать таск менеджер для серьезного исследования расхода памяти не стоит, но в контексте данной задачи этого было достаточно чтобы зафиксировать резкие возрастания ее расхода. Важно было скорее решить проблему, слишком глубоко не вдаваясь в причины ее возникновения.
Согласен, что ИЕ скорее всего более эффективно взаимодействует с родной ОСью и в этом у него есть преимущество (что характерно, подобным образом ведет себя и Сафари на маке — т.е. выглядит так, будто ему вообще не требуется никакой дополнительной памяти для этих операций).
А не пробовали освобождать память через
delete image?Это я ерунду написал, через delete атрибуты объекта удаляют.
Внимательно посмотрел на код, и мне кажется, Вы не совсем правильно сделали выводы. Очевидно, основной профит тут получен от использования [canvas]. Просто при ее использовании можно забывать про объект Image. Если в способ с [canvas], где используется много объектов Image, добавить обнуление src:
Плюс, из кода можно поудалять телодвижения насчет isProcessing — все равно же одна картинка обрабатывается в каждый момент времени вплоть до ее полной загрузки. С другой стороны, можно попробовать увеличить количество картинок, обрабатываемых одномоментно хотя бы до трех, вряд ли будет фриз.
Но вообще, Вы сделали полезное исследование, даже ребята из mozilla не стали этим заморачиваться, например developer.mozilla.org/en-US/docs/Using_files_from_web_applications#Example.3A_Using_object_URLs_to_display_images
PS Код для второго подхода приведен неполностью — нет добавления [canvas] в DOM.
Внимательно посмотрел на код, и мне кажется, Вы не совсем правильно сделали выводы. Очевидно, основной профит тут получен от использования [canvas]. Просто при ее использовании можно забывать про объект Image. Если в способ с [canvas], где используется много объектов Image, добавить обнуление src:
image.src = '' , то все будет так же замечательно (я проверил), как и в последнем примере, с одним Image.Плюс, из кода можно поудалять телодвижения насчет isProcessing — все равно же одна картинка обрабатывается в каждый момент времени вплоть до ее полной загрузки. С другой стороны, можно попробовать увеличить количество картинок, обрабатываемых одномоментно хотя бы до трех, вряд ли будет фриз.
Но вообще, Вы сделали полезное исследование, даже ребята из mozilla не стали этим заморачиваться, например developer.mozilla.org/en-US/docs/Using_files_from_web_applications#Example.3A_Using_object_URLs_to_display_images
PS Код для второго подхода приведен неполностью — нет добавления [canvas] в DOM.
Да, к delete я не стал цепляться, поняв основную суть вопроса. На самом деле я пробовал просто
isProcessing нужен для тех случаев, если в момент обработки добавили еще картинок через форму.
Да, я и начал свои исследования с MDN и в конце концов понял, что никто особо не парился над этим, или по крайней мере не спешил публиковать результаты.
image = null;и что-то не особо помогало. Возможно, если именно src обнулять будет другой результат. Впрочем, все равно, зачем каждый раз создавать, если делать поочередно. Если по три одновременно, то да, тогда без этого не обойтись.
isProcessing нужен для тех случаев, если в момент обработки добавили еще картинок через форму.
Да, я и начал свои исследования с MDN и в конце концов понял, что никто особо не парился над этим, или по крайней мере не спешил публиковать результаты.
Итоговым способом получаются несглаженные превьюшки, некрасивые.
К сожалению, есть такая проблема. Однако, это меньшее из зол, по сравнению с подвешиванием браузера из-за перерасхода памяти, либо с отсутствием превьюшек вообще. В конце концов, превью призваны не радовать глаз, а более наглядно показать, с какими именно изображениями мы имеем дело. И эта задача решена. Никто не мешает Вам после загрузки на сервер делать красивые, супер-сглаженные превью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание превью изображений на клиенте: борьба с прожорливыми браузерами