Работа с объемным DOM в javascript
Запись от Htext размещена 04.04.2025 в 19:37
Показов 5740
Комментарии 0
Метки dom, javascript
|
Сегодня прочитал статью тут о расходах памяти в JS, ее утечках и т.п. И вот что вспомнил из своей недавней практики. Может, кому пригодится. Хотя, в той статье об этом тоже есть. Дело в том, что я какое-то время назад сделал для себя редактор WYSIVYG для html-текстов. Пользуюсь - не нарадуюсь. Даже в итоге как-то обратил внимание, что гораздо реже стал применять Word. Он, если и нужен теперь, то, разве что, для редактирования/просмотра, в основном, чужих документов или для создания таблиц. Одна из функциональностей состоит в том, что есть возможность вставки рисунка, содержащегося в буфере обмена. Путем обычного
Правда, если вставлять из буфера, то рисунок туда должен быть скопирован из растрового графического приложения (например, из Paint) или через PrintScreen. При копировании из Word (по крайней мере, из Word2003, который я использую) возникают сложности, это надо разрабатывать дополнительно, делать дополнительный запрос на сервер. Пока я этого не реализовал. Но, это мелочи. Т.к. можно из Word вначале скопировать в Paint, а уже оттуда, скопировав в буфер, вставить на страницу, открытую в браузере в режиме редактирования. Вставку можно делать или непосредственно на страницу куда-нибудь (в пределах редактируемой области, конечно), или в предварительно вставленный готовый шаблон разметки (в визуальном режиме). Шаблоны у меня для каждого сайта сделаны, их вставка делается путем 2-3 кликов. Не по теме: Попутно, после клика мышью по рисунку, можно, в панели моего редактора, нажать кнопку запуска Paint (если дело происходит в Windows7; для Linux я пока реализацию этого не делал) и тогда, через пару секунд, рисунок будет открыт в этом редакторе и готов для редактирования. Но, это уже к теме не относится. После того, как рисунок предварительно вставлен, можно, кликнув по нему дважды (dblclick), вызвать всплывающее меню, где можно задать атрибуты (как минимум, это - src, alt, title, class; если в теге img есть и иные атрибуты - они также будут показаны и доступны для редактирования). Кроме того, в меню показывается и сам код рисунка в виде "data:image/png;base64,iVBORw0KGgoAAAANSUhEJUgAABF4A AAAQ4CAIKOAAABnsVYUAAAgA...". Это - для того, чтобы хотя бы ориентировочно убедиться, что там нет ничего подозрительного. А то мало ли... Изначально рисунок вставляется по протоколу
Так вот, в 24-м Firefox после вставки сравнительно больших рисунков (где-то от 500-800 кБ, если по протоколу data  возникает проблема: становится сложно прокрутить страницу вверх-вниз. Вплоть до ее подвисания. Интересно, что уже в 36-м Firefox такой проблемы нет. Видимо, там как-то усовершенствовали работу с памятью(?) и/или отображением страницы... , по сравнению с 24-м. Так более того, если попытаться сохранить рисунок на сервере (в формате png), то происходят странные вещи: содержимое рисунка уходит на сервер, тот в ответ присылает подтверждение с кодом 200 (если все хорошо), но... тело ответа - может быть пустым, как будто ответа не было вообще; а он должен быть. Причем, такое наблюдается не всегда. Видимо, это зависит от загруженности процессора и расхода оперативной памяти другими приложениями. Как я решил проблемы. При прокрутке страницы тег, содержащий код рисунка, делается display:none (с сохранением высоты и ширины родительского тега, чтобы панель редактирования атрибутов рисунка не дергалась), а затем, после остановки прокрутки, возвращается предыдущее значение свойства display. Ну, а для борьбы с пустым ответом сервера использую setTimeout, направляя запрос на сохранение не сразу после нажатия кнопки "Сохранить рисунок", а через короткое время. Не по теме: И, да, перед каждым целевым запросом к серверу делаю проверочный запрос на тестовый поддомен, чтобы убедиться, что запрос пошел именно на локальный сервер, а не в интернет. А то, помнится, много с этим раньше проблем было, когда постоянно переключаешься с локального сервера на сервер в интернете и обратно. Видимо, после нажатия кнопки сохранения браузер должен проделать какие-то свои внутренние операции, а потом уже делать запрос на сервер. Возможно, в 24-м браузере эти операции недостаточно оптимизированы... Т.е. я понял из практики следующее. При перемещении по странице тегов, содержащих большой объем контента (textContent), следует для таких тегов временно делать display:none. Неважно, как они перемещаются - то ли путем прокрутки, то ли при помощи мыши (если в режиме редактирования), то ли средствами JS. Думаю, что это может быть актуальным и для более новых браузеров. Правда, саму проблему с перемещением я связываю не столько с перерасходом памяти, сколько (как мне кажется) с неоптимальной работой отображения страницы в окне 24-го Firefox по сравнению с 36-м. | |||||||||||||||
Метки dom, javascript
Размещено в Без категории
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Всего комментариев 0
Комментарии
