Как переполнение: скрыто; & border-radius в контейнере вызывает массовое замедление до "Paint/Render Layer" внутри контейнера, только в IE?

Ответ 1

После гораздо большего тестирования я думаю, что начинаю понимать, что происходит здесь. Это чисто основано на наблюдении, хотя, поэтому я все равно буду увлекаться более авторитетным ответом, если у кого-нибудь есть.

Что его вызывает?

Это происходит, только если все это верно:

• Браузер IE (любая версия)
• Элемент предка, который мы будем называть X, содержит как overflow: hidden, так и border-radius (или -ms-border-radius). В моем тестировании это не происходит, если разные предки в одной ветки имеют эти стили.
• Существует много сложных элементов, таких как пути SVG или div-width, которые находятся в ветке DOM, где они или элемент между ними и элементом X имеют position: absolute; или position: relative;

Проблема также кажется более выраженной пропорционально количеству элементов, затронутых position: absolute;/relative, и их сложности. В случаях, когда были обнаружены пути SVG в гибко масштабируемом контейнере SVG с пропускной способностью% -width с% padding-bottom для фиксированного соотношения сторон, например, проблема была очень выраженной; если эта ветвь была задана position: static, но другая ветвь имела div-width с предком position: absolute;, тогда проблема по-прежнему наблюдалась по сравнению с удалением одного из overflow: hidden; или border-radius, но была гораздо менее серьезной.

Но почему?

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

Я заметил, что вычисления offsetWidth для элементов между X и путями проходили весь путь до путей, которые не имели для меня никакого смысла и вызвали связанный с ним вопрос потому что пути в контейнере SVG, безусловно, не могут влиять на компоновку вне контейнера.

Я также заметил, что, исследуя это, другие браузеры, в частности, старая версия Chrome, похоже, имели другую проблему: элементы, которые должны были быть скрыты, были рендеринг, вызывающий замедление.

Сложив их вместе, я думаю, что есть правдоподобное объяснение того, что происходит здесь. Если это правда, по иронии судьбы, мои проблемы с производительностью были вызваны попыткой IE IE, направленной на то, чтобы оптимизировать производительность и избежать таких проблем, как связанная с Chrome проблема Chrome.

Если эта теория верна, что-то вроде этого происходит в IE:

• Он видит overflow: hidden; и делает вывод, что он может повысить производительность, идентифицируя элементы, которые полностью находятся за пределами границ элемента, прежде чем делать на них события перерисовывания /reflow/paint и т.д.
• Он видит position: absolute; и position: relative; дальше DOM и заключает, что они и их дети потенциально могут быть полностью вне контейнера и могут быть проигнорированы как
• Во время таких событий, как перерисовка и перепланирование, он сначала циклически проходит через все эти элементы и проверяет, что они не полностью за пределами границ. Это происходит даже без border-radius, но в таких случаях оно тривиально и принимает миллисекунды.
• ... однако IE отмечает граничный радиус и заключает, что форма этого элемента overflow: hidden не является прямоугольником, и поэтому требуется более сложный расчет, чтобы определить, что находится за пределами границ.
• Предположительно, он также заключает, что пути SVG нужно сравнивать на основе их фактических форм, а не их простых ограничивающих прямоугольных координат, так как это уже не просто сравнение параллельных прямоугольников.
• Внезапно вычисление для проверки того, можно ли игнорировать элемент во время красок/перерисовки/переплавки, стало сложным. Если повторять сотни раз для сотен элементов, он значительно ухудшает производительность при каждом запуске события.

Как это исправить?

Если вы можете, просто переместите overflow: hidden или border-radius в дочерний элемент, чтобы они не были на одном элементе. Выполнение задания.

Для меня, однако, я создаю плагин, который должен быть способен быть удаленным в любом месте и не будет иметь никакого контроля над страницами, на которых он был развернут. Я не знаю, как я могу заставить IE отключить это поведение.

Лучший подход, который я могу придумать, состоит в том, чтобы предположить, что стиль border-radius не имеет существенного значения для эстетики и что overflow: hidden; может быть существенным для структуры, и поэтому, если браузер IE, найдите дерево предков и удалите border-radius из любого элемента, у которого есть и это, и overflow: hidden;.

В моем приложении уже используется jQuery, поэтому этот тест выглядит примерно так:

if( isAnyIE() ) {
  $container.parentsUntil("body").filter(function(){

    var $this = $(this),
      overflow = $this.css('overflow');
    return ( overflow === 'hidden' && hasBorderRadius( $this ) );

  }).addClass( 'remove-border-radius' ); 
}

function hasBorderRadius( $element ){
  function getNum( style ){
    return parseFloat( $element.css( 'border-'+style+'-radius' ) ) || 0;
  }
  var number = 0;

  number += getNum( 'top-left' );
  number += getNum( 'bottom-left' );
  number += getNum( 'top-right' );
  number += getNum( 'bottom-right' );

  $element = null;

  return !!number;
}

function isAnyIE(){
  // isIE(): use conditional comments and classes, see https://stackoverflow.com/a/18615772/568458
  // isIE10: use user agent like navigator.appVersion.indexOf("MSIE 10") !== -1;
  // isIE11: use user agent like !!navigator.userAgent.match(/Trident.*rv[ :]*11\./);

  return isIE11() || isIE10() || isIE();
}

С CSS как:

.remove-border-radius {
  border-radius: 0 0 0 0 !important;
  -ms-border-radius: 0 0 0 0 !important;
}

Ответ 2

Проблема была привлечена к Microsoft внимание в этот отчет об ошибке, написанный Джоппе Кроном в феврале 2014 года:

[IE 9] [IE 11] div с граничным радиусом и переполнением за исключением видимого изменения размера при заполнении div с помощью позиции относительно

Перерисовывание страницы выполняется очень плохо, когда есть много большие элементы DIV с комбинацией положения "абсолютный", "фиксированный", или "относительный", переполнение, отличное от "видимого" и радиус границы. Это можно увидеть при изменении размера окна или прокрутки. Отдельные события рисования могут занять до 1,5 секунд, в результате чего страница перестает реагировать.

Эта проблема производительности появляется в IE 11 и IE 9, но не в IE 10.

<ч/" > Единственный существенный ответ Microsoft был опубликован в апреле 2016 года. Он не обеспечивает решение или обходное решение:

[...] Мы рассмотрели проблему, о которой вы сообщили очень близко, и нашли он очень похож на аналогичные сообщенные проблемы. Ни один из наших обычных резолюции ( "BY DESIGN", "DUPLICATE", "FIXED" и т.д.) в точности совпадают поэтому мы отмечаем это как "WONT FIX" из-за отсутствия что-то лучше, но то, что мы действительно имеем в виду, хорошо справляется с этим в агрегированный вид, а не смотреть на этот точный инцидент в этой точной ситуации. [...]

Все лучшее, команда MS Edge Team

Состояние ошибки: Закрыто, поскольку не будет исправлено