К сожалению, есть такая проблема. Однако, это меньшее из зол, по сравнению с подвешиванием браузера из-за перерасхода памяти, либо с отсутствием превьюшек вообще. В конце концов, превью призваны не радовать глаз, а более наглядно показать, с какими именно изображениями мы имеем дело. И эта задача решена. Никто не мешает Вам после загрузки на сервер делать красивые, супер-сглаженные превью.
Да, к delete я не стал цепляться, поняв основную суть вопроса. На самом деле я пробовал просто
image = null;
и что-то не особо помогало. Возможно, если именно src обнулять будет другой результат. Впрочем, все равно, зачем каждый раз создавать, если делать поочередно. Если по три одновременно, то да, тогда без этого не обойтись.
isProcessing нужен для тех случаев, если в момент обработки добавили еще картинок через форму.
Да, я и начал свои исследования с MDN и в конце концов понял, что никто особо не парился над этим, или по крайней мере не спешил публиковать результаты.
Смотрел. Имеет смысл. Вы можете сохранять где-то в массиве (или каком-то объекте, отображающем загрузку) исходные объекты типа File. Сами по себе они ничего практически не весят, но их можно приаттачивать к запросу, тем самым отправляя оригинал. Выбор файлов, естественно тоже ничего не жрет (еще бы вывод системного окошка требовал ресурсов! :), а от readAsDataURL нам удалось отказаться.
Да, я смотрел именно в колонку «Память». Конечно, я понимаю, что использовать таск менеджер для серьезного исследования расхода памяти не стоит, но в контексте данной задачи этого было достаточно чтобы зафиксировать резкие возрастания ее расхода. Важно было скорее решить проблему, слишком глубоко не вдаваясь в причины ее возникновения.
Согласен, что ИЕ скорее всего более эффективно взаимодействует с родной ОСью и в этом у него есть преимущество (что характерно, подобным образом ведет себя и Сафари на маке — т.е. выглядит так, будто ему вообще не требуется никакой дополнительной памяти для этих операций).
В статье упоминается, что я попросту наблюдал за стандартным таск менеджером. Никаких других, более точных замеров не производил. А что, ИЕ куда-то «прячет» память?
Понимаете, изначально вообще не было цели устраивать тесты браузеров. Цель была найти подход, позволяющий генерить превью для относительно больших картинок, не выходя за разумные рамки в плане использования памяти. Я сейчас пользуюсь Яндексом, поэтому все смотрю изначально в нем. Но при этом важно было понимать, что применяемые оптимизации проявляются не только в моем браузере, поэтому я стал параллельно проверять в остальных, установленных в системе. Можно было бы, наверное, и не включать Хром. Но тогда для многих выбор показался бы еще более странным :)
Если посмотреть на все это немного под другим углом, то выбор и не покажется таким уж странным: представлено три основных движка, при этом самый популярный из них в двух исполнениях.
Насчет достойной альтернативы — вопрос спорный. Да, в той самой Опере, возможно, есть некоторые фичи, которые Вам дороги. И в то же время с внедрением новых фич у остальных, 12-я версия все более безнадежно будет устаревать и в конце концов минусы перевесят плюсы.
Но ок, пока не буду списывать со счетов. По крайней мере мысленно :) Если будет время, попробую в ней прогнать.
Конкретно в моем приложении они пока еще даже не отправляются на сервер :) Но, разумеется, и не планирую так делать. Тем более, мне не нравится как некоторые браузеры сглаживают уменьшенные таким образом изображения.
Скажу пару слов о том, какова конечная цель задуманного. Пользователю необходимо иметь возможность загружать сразу большие альбомы и подборки фотографий. При этом, закинув все фотографии из папки, он, возможно, захочет какие-то тут же убрать из списка. А некоторые, вероятно, сразу же повернуть. Если делать по старинке, т.е. грузить сразу после добавления на сервер, а в ответ получать ссылки на уже уменьшенные изображения, то а) серверу надо будет заниматься обработкой как можно скорее, и б) нужно проделывать лишнюю работу: удаление ненужных фотографий и осуществление поворота картинок. Теперь же, обработку можно отложить, но при этом пользователь будет моментально видеть результат (пусть и приблизительный). Плюс данные о повороте будут отправляться сразу с изображением и на сервере можно сразу же повернуть изображение как надо, параллельно с созданием превьюхи. Более того, я думаю пойти еще дальше и на клиенте считать md5 (или sha1) хеш изображения и предупреждать пользователя о вероятных дублях.
Тут, конечно, палка о двух концах. Если переписать таким образом библиотеку, то, скорее всего, ее размер вырастет. Для сайтов/приложений где все равно используется jQuery (а их большинство) это даст только бесполезное увеличение объема. Но с другой стороны, конечно, позволит не подключать увесистую библиотеку там, где это не требуется.
Оптимальным было бы сделать некую jqLite (как в Angular, кажется), где реализовать только ту часть функционала, которая используется матрешкой. Тогда ее можно было бы использовать в тех приложениях, где нет необходимости во всей jQuery и дало бы экономию по объему кода. Но это требует больше усилий автора на разработку, а он мог бы потратить их на улучшения непосредственно самой матрешки.
С третьей стороны, сейчас на сайте jQuery можно самому собрать лайт-версию. Возможно, это самый компромиссный вариант. Только тогда автору в документации надо указать, что конкретно используется.
isProcessing нужен для тех случаев, если в момент обработки добавили еще картинок через форму.
Да, я и начал свои исследования с MDN и в конце концов понял, что никто особо не парился над этим, или по крайней мере не спешил публиковать результаты.
Да, я смотрел именно в колонку «Память». Конечно, я понимаю, что использовать таск менеджер для серьезного исследования расхода памяти не стоит, но в контексте данной задачи этого было достаточно чтобы зафиксировать резкие возрастания ее расхода. Важно было скорее решить проблему, слишком глубоко не вдаваясь в причины ее возникновения.
Согласен, что ИЕ скорее всего более эффективно взаимодействует с родной ОСью и в этом у него есть преимущество (что характерно, подобным образом ведет себя и Сафари на маке — т.е. выглядит так, будто ему вообще не требуется никакой дополнительной памяти для этих операций).
Если посмотреть на все это немного под другим углом, то выбор и не покажется таким уж странным: представлено три основных движка, при этом самый популярный из них в двух исполнениях.
P.S. По 12-й Опере добавил краткий UPD
Но ок, пока не буду списывать со счетов. По крайней мере мысленно :) Если будет время, попробую в ней прогнать.
Скажу пару слов о том, какова конечная цель задуманного. Пользователю необходимо иметь возможность загружать сразу большие альбомы и подборки фотографий. При этом, закинув все фотографии из папки, он, возможно, захочет какие-то тут же убрать из списка. А некоторые, вероятно, сразу же повернуть. Если делать по старинке, т.е. грузить сразу после добавления на сервер, а в ответ получать ссылки на уже уменьшенные изображения, то а) серверу надо будет заниматься обработкой как можно скорее, и б) нужно проделывать лишнюю работу: удаление ненужных фотографий и осуществление поворота картинок. Теперь же, обработку можно отложить, но при этом пользователь будет моментально видеть результат (пусть и приблизительный). Плюс данные о повороте будут отправляться сразу с изображением и на сервере можно сразу же повернуть изображение как надо, параллельно с созданием превьюхи. Более того, я думаю пойти еще дальше и на клиенте считать md5 (или sha1) хеш изображения и предупреждать пользователя о вероятных дублях.
Еще стоит отметить, что все работает отлично также в ИЕ 10+
тут и камень в сторону плюсов и камешек предыдущему комментатору, и просто уместная шутка с налетом «для тех кто в теме» :)
Оптимальным было бы сделать некую jqLite (как в Angular, кажется), где реализовать только ту часть функционала, которая используется матрешкой. Тогда ее можно было бы использовать в тех приложениях, где нет необходимости во всей jQuery и дало бы экономию по объему кода. Но это требует больше усилий автора на разработку, а он мог бы потратить их на улучшения непосредственно самой матрешки.
С третьей стороны, сейчас на сайте jQuery можно самому собрать лайт-версию. Возможно, это самый компромиссный вариант. Только тогда автору в документации надо указать, что конкретно используется.