Estou usando o GWT para criar um aplicativo HTML em que o desempenho esteja correto em geral.

Às vezes, ele pode carregar muitos objetos no DOM e o aplicativo fica lento. Eu usei o Chrome Developer Tools Profiler para ver onde esse tempo foi gasto (sob o Google Chrome depois que o aplicativo é compilado, ou seja, sem sobrecarga no GWT), e está claro que os métodosgetAbsoluteLeft () / getBoundingClientRect () consumir a maior parte deste tempo.

Aqui está a implementação usada no Chrome (com.google.gwt.dom.client.DOMImplStandardBase):

private static native ClientRect getBoundingClientRect(Element element) /*-{
  return element.getBoundingClientRect && element.getBoundingClientRect();
}-*/;

@Override
public int getAbsoluteLeft(Element elem) {
  ClientRect rect = getBoundingClientRect(elem);
  return rect != null ? rect.getLeft()
     + elem.getOwnerDocument().getBody().getScrollLeft()
     : getAbsoluteLeftUsingOffsets(elem);
}

Isso faz sentido para mim, quanto mais elementos no DOM, mais tempo pode demorar para calcular posições absolutas.Mas é frustrante porque às vezes você sabe que apenas uma subparte do seu aplicativo foi alterada, enquanto esses métodos ainda demoram para calcular o posicionamento absoluto, provavelmente porque ele desnecessariamente verifica novamente um monte de elementos DOM. Minha pergunta não é necessariamente orientada para o GWT, pois é um problema relacionado ao navegador / javascript:

Existe alguma solução conhecida para melhorar o problema getAbsoluteLeft / javascript getBoundingClientRect do GWT para aplicativos de elementos DOM grandes?

Não encontrei nenhuma pista na internet, mas pensei em solução como:

(reduzindo o número de chamadas para esses métodos :-) ...isolar parte do DOM através de iframe, a fim de reduzir o número de elementos que o navegador deve avaliar para obter uma posição absoluta (embora isso dificulte a comunicação de componentes ...)na mesma idéia, pode haver alguma propriedade css (overflow, position?) ou algum elemento html (como iframe) que diz ao navegador para pular uma parte inteira do dom ou simplesmente ajudar o navegador a obter uma posição absoluta mais rápida

EDITAR:

Usando o depurador TimeLine do Google Chrome e realizando uma ação específica, embora haja muitos elementos no DOM, tenho o desempenho médio:

Recalcule o estilo: quase zeroPintura: quase 1 msLayout: quase 900ms

Layout leva 900ms através do método getBoundingClientRect. Esta lista de páginastodos os métodos que acionam o layout no WebKit, incluindo getBoundingClientRect ...

Como eu tenho muitos elementos no dom que não são impactados pela minha ação, eu assumolayout está fazendo recálculo em todo o DOM enquantopintura é capaz através da propriedade css / árvore DOM de restringir seu escopo (eu posso vê-lo através do MozAfterPaintEvent no firebug por exemplo).

Exceto agrupar e chamar menos os métodos que acionam o layout,alguma pista sobre como reduzir o tempo de layout?

Alguns artigos relacionados:

Minimizando o refluxo do navegador