Какие действия и события заставляют браузер перерисовывать всю область просмотра?

Я пытаюсь реализовать wmd-редактор из репозитория кода Google (например, тот, который используется в stackoverflow прямо здесь), и у меня возникла проблема.

Когда вы вводите текст в текстовое поле, в браузере запускаются две операции рисования. Один для перерисовки самого текстового поля, а другой для перерисовки панели предварительного просмотра. Вы можете наблюдать, как это происходит в stackoverflow, открыв инспектор Chrome и используя вкладку временной шкалы при вводе текста в поле вопроса.

Но на моей странице браузер перерисовывает всю область просмотра, когда ему приходится выполнять эти операции рисования. И это занимает гораздо больше времени ... около 100 мс для каждой операции рисования на моей странице по сравнению с 1 мс для stackoverflow.

В моем тестировании это похоже на css ... Я могу воссоздать это поведение на странице примера wmd-new, удалив все стили.

Моя страница еще не общедоступна, но, надеюсь, я могу задать общий вопрос ... что заставит браузер перерисовывать всю область просмотра при изменении dom вместо того, чтобы просто перерисовывать эту часть dom?

Взгляд на то, о чем я здесь говорю. введите описание изображения здесь


javascript css dom wmd wmd-editor
person Bob Ralian    schedule 24.02.2011    source источник
comment
Вы видите во всех браузерах? Кроме того, происходит ли прозрачность или затенение внутри или вокруг редактора? Все, что имеет непрозрачность <1, всегда сильно замедляет работу.   -  person balpha    schedule 25.02.2011
comment
Спасибо, balpha, ваш комментарий был точным. Это была box-shadow на элементе body. К сожалению, это означает, что мне нужно изменить весь мой дизайн, чтобы приспособить эту функциональность. Но очень рада, что нашла проблему. Я сходил с ума, пытаясь понять это.   -  person Bob Ralian    schedule 25.02.2011

Ответы (2)


arrow_upward
6
arrow_downward

АГА! А-а-а-а-а! (простите за энтузиазм)

Проблема в том, что я использовал свойство css box-shadow для кадрирования своей страницы. Перекомпоновка / перерисовка содержимого занимает больше времени, когда браузеру необходимо вычислять эту тень при каждом изменении (~ 100 мс против ~ 1 мс). А при использовании wmd-editor вы обновляете dom при каждом нажатии клавиши, так что разница складывается. И эффект наиболее преувеличен, когда браузер развернут, поскольку он пересчитывает всю область просмотра.

Так что, возможно, это одна из причин, по которой stackoverflow не имеет рамок или теней на странице ... только чистые края.

Вы можете увидеть, что я имею в виду, на этой странице примера. Откройте его в firefox, разверните страницу и начните печатать. Теперь используйте firebug, чтобы удалить свойство box-shadow в элементе body, снова закройте firebug и повторите попытку. Большая разница.

Спасибо Балфе за его комментарий, который был точным.

person Bob Ralian    schedule 25.02.2011
comment
Обновление: еще раз взглянул на ссылку, которую я дал, и я больше не замечаю никаких задержек в Chrome или Firefox. Я думаю, это потому, что браузеры становятся намного лучше. Приветствую войну браузеров за продвижение Интернета! - person Bob Ralian; 03.04.2012

arrow_upward
3
arrow_downward

Посмотрите эту презентацию, слайд 70 и следующие. Они немного объясняют, что может вызвать переформатирование и перерисовку.

http://www.slideshare.net/nzakas/high-performance-javascript-webdirections-usa-2010

Без конкретного кода / CSS сложно ответить, но я могу сказать что-то общее, например, если измененный фрагмент DOM влияет на другие элементы на странице :)

Также обратите внимание, что в stackoverflow WMD, когда вы вводите новую строку, это также вызывает перерисовку всего окна просмотра. Так, может быть, это как-то связано с тем, что ваша WYSIWYG-область не имеет четко определенных ширины и высоты? Я предполагаю, что если вы укажете им ширину и высоту, они не повлияют на другие элементы на странице.

person AlfaTeK    schedule 24.02.2011
comment
Да, работаю над урезанным примером, который я могу опубликовать. Я не думаю, что опубликованная вами презентация полностью затрагивает эту проблему, поскольку это не проблема многих изменений dom, вызывающих множество перекомпоновок. Это проблема того, что одна инъекция dom занимает больше времени, чем следовало бы для ее перекомпоновки. - person Bob Ralian; 25.02.2011