Summary: | [Qt][WK2] Child layers appear in wrong position when scrolling | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Noam Rosenthal <noam> | ||||||||||||
Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> | ||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||
Severity: | Normal | CC: | abecsi, gustavo, hausmann, hyatt, jturcotte, kenneth, simon.fraser, webkit.review.bot, xan.lopez, zoltan | ||||||||||||
Priority: | P2 | Keywords: | Qt | ||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||||
Hardware: | Unspecified | ||||||||||||||
OS: | Unspecified | ||||||||||||||
Attachments: |
|
Description
Noam Rosenthal
2012-01-25 17:11:26 PST
Created attachment 124037 [details]
Patch
Comment on attachment 124037 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=124037&action=review > Source/WebKit2/WebProcess/WebPage/WebPage.cpp:795 > Frame* frame = m_page->mainFrame(); > + m_fixedVisibleContentRect = rect; > > frame->view()->setFixedVisibleContentRect(rect); > } can't you receive it from the FrameView instead? or is that a performance issue? The scrolling of the layers seems to be done by a scroll layer. It would probably be better to prevent the use of this layer instead, RenderLayerCompositor::requiresScrollLayer seems to do exactly that. Comment on attachment 124037 [details]
Patch
Will try another approach based on comments.
Created attachment 124137 [details]
Patch
Created attachment 124138 [details]
Patch
Comment on attachment 124138 [details] Patch Attachment 124138 [details] did not pass gtk-ews (gtk): Output: http://queues.webkit.org/results/11163476 Created attachment 124212 [details]
Patch
Comment on attachment 124212 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=124212&action=review > Source/WebCore/platform/ScrollView.h:127 > + virtual void delegatesScrollingDidChange() { } Why is this public? (In reply to comment #9) > (From update of attachment 124212 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=124212&action=review > > > Source/WebCore/platform/ScrollView.h:127 > > + virtual void delegatesScrollingDidChange() { } > > Why is this public? Oversight :) Will make protected when committing. Created attachment 124302 [details]
Patch
Comment on attachment 124302 [details] Patch Clearing flags on attachment: 124302 Committed r106121: <http://trac.webkit.org/changeset/106121> All reviewed patches have been landed. Closing bug. Since this change MiniBrowser does not print the new tiles after the kinetic animation finishes. If I remove: // This applies when the application UI handles scrolling, in which case RenderLayerCompositor doesn't need to manage it. if (m_renderView->frameView()->delegatesScrolling()) return false; from WebCore/rendering/RenderLayerCompositor.cpp: RenderLayerCompositor::requiresScrollLayer, it works again. This might be because !m_renderView->frameView()->platformWidget() is actually true. Since I'm not familiar with this code, I do not know if this is actually a revealed bug somewhere else, or is that return not needed. (In reply to comment #14) > Since this change MiniBrowser does not print the new tiles after the kinetic animation finishes. > > If I remove: > > // This applies when the application UI handles scrolling, in which case RenderLayerCompositor doesn't need to manage it. > if (m_renderView->frameView()->delegatesScrolling()) > return false; > > from WebCore/rendering/RenderLayerCompositor.cpp: RenderLayerCompositor::requiresScrollLayer, it works again. > This might be because !m_renderView->frameView()->platformWidget() is actually true. !m_renderView->frameView()->platformWidget() is always true in WebKit2. > > Since I'm not familiar with this code, I do not know if this is actually a revealed bug somewhere else, or is that return not needed. We delegate scrolling in WebKit2, so we shouldn't have the compositor control these layers... I will investigate, but I have less experience with the scrolling code, so if someone else wants to have a look be my guest. (In reply to comment #15) Jocelyn helped finding the cause of this issue, I opened a bug for it: https://bugs.webkit.org/show_bug.cgi?id=77338 |