Как работает переполнение: скрыто; & border-radius в контейнере вызывает значительное замедление рисования / рендеринга слоя в контейнере, только в IE?

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

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

Кажется, это произойдет только в том случае, если все это правда:

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

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

Но почему?

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

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

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

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

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

• Он видит overflow: hidden; и приходит к выводу, что он может улучшить производительность, идентифицируя элементы, которые полностью выходят за границы элемента, прежде чем выполнять для них события перерисовки / перекомпоновки / рисования и т. Д.
• Он видит 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;
}

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

[IE 9] [IE 11] div с радиусом границы и переполнением кроме видимых, медленное изменение размера при заполнении div с положением относительным

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

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

[...] Мы очень внимательно изучили проблему, о которой вы сообщили, и обнаружили, что она очень похожа на аналогичные проблемы, о которых сообщалось. Ни одно из наших обычных разрешений («ПО ДИЗАЙНУ», «ДУПЛИКАТ», «ФИКСИРОВАННЫЙ» и т. Д.) Точно не соответствует этой ситуации, поэтому мы отмечаем его как «НЕ ИСПРАВЛЯЕМ» из-за отсутствия чего-либо лучшего, но на самом деле мы имеем в виду то, что мы я буду иметь дело с этим в совокупности, а не смотреть на этот конкретный инцидент в этой конкретной ситуации. [...]

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

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