Bug 75015 - Setting scrollTop / scrollLeft should not cause a layout
: Setting scrollTop / scrollLeft should not cause a layout
Status: NEW
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To: Nobody
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-21 10:35 PST by Julien Chaffraix
Modified: 2015-05-14 04:30 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Chaffraix 2011-12-21 10:35:21 PST
Currently the setters for scrollTop and scrollLeft forces a layout each time they are called:

void Element::setScrollTop(int newTop)
{
    document()->updateLayoutIgnorePendingStylesheets();
    if (RenderBox* rend = renderBox())
        rend->setScrollTop(static_cast<int>(newTop * rend->style()->effectiveZoom()));
}

The only reason to do that is to be able to clamp the value to the height / width of the box (see the logic in RenderLayer).

This is confusing from a web-developer perspective and also the layout could be postponed until really necessary.
Comment 1 Julien Chaffraix 2012-11-07 15:20:30 PST
There is one big issue with coalescing layouts: we cannot scroll until we actually do the layout as we need to clamp and scrolling dispatches the 'scroll' event. If the page listens to those events, I haven't found a good way to defer scrolling until we layout without breaking event dispatching.
Comment 2 Lucas Wiener 2015-05-14 04:30:29 PDT
I've posted this Stack Overflow question regarding the performance of scrollTop/Left in Safari: http://stackoverflow.com/questions/30218002/element-scrolltop-left-is-really-slow-in-safari-why/30218327#30218327

I assume this is due to the layout being forced for each call to the methods.
Is it possible to look how Blink handles this?
As shown in the Stack Overflow question, Blink executes the test function in ~50 ms while Safari executes it in ~1500 ms.

Kind regards