7
HTML 테이블을 사용하여 웹 기반 응용 프로그램을 구축하고 있습니다. 이 테이블의 특이한 특성 중 하나는 상단 행과 왼쪽 열이 고정되어 있다는 점입니다 (Excel과 유사). 작은 jQuery와 CSS를 사용하여이 작업을 수행했습니다.브라우저를 다시 그리기 전 * javascript를 강제 실행하십시오 (jsFiddle 예제)
내 코드를 트리거하는 jQuery 이벤트는 $ (window) .scroll 이벤트이며이 이벤트에서 호출 한 코드가 실행되기 전에 대부분의 브라우저 (Chrome 및 IE)가 페이지를 다시 그립니다. 결과적으로 왼쪽 열과 맨 위 행은 테이블의 나머지 부분을 "따라 잡기"위해 초당 분할됩니다.
내 문제를 설명하기 위해 stripped down jsFiddle example을 제공했습니다. 참고 : 테이블이 너무 작아서 (상대적으로 말하면) 내용이 비어있는 경우 지연이별로 눈에 띄지 않습니다. 그럼에도 불구하고, 그것은 (당신이 파이어 폭스를 사용하지 않는다고 가정 할 때) 거기에 있습니다. 이 지연을 제거 할 수있는 방법이 있습니까?
감사합니다.
어쩌면 raf 작동 방식을 오해하고 있습니다. 그러나 문제가 완전히 풀리지 않는 것은 내 문제가 프레임을 너무 빨리 그려야하기 때문에 발생합니다. 그게 맞습니까? 아니면 내가 얻지 못하는 것이 있습니까? – ihake
'requestAnimationFrame'은 다시 칠하기 직전에 명령을 내릴 수있게합니다. 따라서 requestAnimationFrame에서 변경 한 내용은 다음 다시 그리기에 표시됩니다. 웹 페이지를 그릴 때 브라우저가 호출하는 콜백입니다. 스크롤 문제가 발생한 직후 (또는 의심되는 항목) 또는 너무 많은 스크롤 콜백이 발생하여 (즉, 프레임 당 1 이벤트 이상) syncHeadColumns를 호출하면 문제가 발생할 가능성이 큽니다. 이로 인해 시각적 업데이트가 지연됩니다 (개인적으로 이것이 가능할 확률이 높음). 어쨌든 : 나는'requestAnimationFrame'이 두 가지 모두를 도울 수 있어야한다고 생각한다. –
내가 시도 할 것이 아니라'requestAnimationFrame'에서'syncHeadColumns'를 호출하는 대신 scroll 이벤트를 호출합니다. 그것은'syncHeadColumns'에 대한 호출의 양을 줄이면서 헤더를 부드럽게 유지해야합니다. 또한 브라우저가 아닌 경우 다시 그리기 및 리플 로우 동작이 브라우저에서 작동하는 방식을 확인할 수도 있습니다. 변경 될 때 리플 로우를 유발하는 특정 요소 및 CSS 속성이 있습니다. 이것은'position : fixed' 엘리먼트의 대부분의 속성에 해당하지 않아야합니다. 그러나 여러분의 코드에서 리플 로우를 일으키는 무언가가 누락되었을 수 있습니다. –