Bug 77339

Summary: [Qt] Painting on wheel scroll
Product: WebKit Reporter: Allan Sandfeld Jensen <allan.jensen>
Component: WebKit2Assignee: Allan Sandfeld Jensen <allan.jensen>
Status: RESOLVED FIXED    
Severity: Normal CC: abecsi, menard, webkit.review.bot, zoltan
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch none

Allan Sandfeld Jensen
Reported 2012-01-30 07:45:19 PST
When using the Minibrowser in default touch mode and scroll down a long page using the mouse wheel, you will at some point reach an unpainted part of the screen. Panning the screen using touch-mock will trigger the repaint. The issue seems to be that wheel-scroll does not send new expose events to the web-process. This has been a regression since painting became better optimized.
Attachments
Patch (6.23 KB, patch)
2012-01-30 07:49 PST, Allan Sandfeld Jensen
no flags
Patch (6.94 KB, patch)
2012-01-31 06:45 PST, Allan Sandfeld Jensen
no flags
Allan Sandfeld Jensen
Comment 1 2012-01-30 07:49:53 PST
Kenneth Rohde Christiansen
Comment 2 2012-01-30 08:26:44 PST
Comment on attachment 124550 [details] Patch wouldnt it be better to call the viewportTrajectoryVectorChanged ?
Andras Becsi
Comment 3 2012-01-30 08:43:55 PST
I think this is the same issue as https://bugs.webkit.org/show_bug.cgi?id=77338.
Allan Sandfeld Jensen
Comment 4 2012-01-30 09:00:17 PST
(In reply to comment #2) > (From update of attachment 124550 [details]) > wouldnt it be better to call the viewportTrajectoryVectorChanged ? TrajectoryVectorChanged only tells which direction we are going to move in, not what we have actually moved. The normal animated process is: On animate start: TrajectoryVectorChanged On animate end: VisibleContentRectAndScaleChanged (called from _q_resume) This is just a non animated version doing the same as animate end. It could be achieved by calling suspend and resume in a quick succession, but that seems silly.
Andras Becsi
Comment 5 2012-01-30 09:51:25 PST
(In reply to comment #3) Having a second look, it is a separate issue, and we need a call to updateVisibleContentRectAndScale on wheel scrolling as well. Sorry for the noise.
Alexis Menard (darktears)
Comment 6 2012-01-31 03:22:24 PST
Comment on attachment 124550 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=124550&action=review > Source/WebKit2/UIProcess/API/qt/qquickwebview.cpp:314 > +void QQuickWebViewPrivate::_q_visibleContentRectAndScaleChanged() Would it be better to make updateVisibleContentRectAndScale a slot?
Allan Sandfeld Jensen
Comment 7 2012-01-31 05:03:09 PST
(In reply to comment #6) > (From update of attachment 124550 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=124550&action=review > > > Source/WebKit2/UIProcess/API/qt/qquickwebview.cpp:314 > > +void QQuickWebViewPrivate::_q_visibleContentRectAndScaleChanged() > > Would it be better to make updateVisibleContentRectAndScale a slot? Well it is in QQuickWebViewPrivate, and all the other slots there have the _q_something form.
Alexis Menard (darktears)
Comment 8 2012-01-31 05:12:29 PST
Comment on attachment 124550 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=124550&action=review >>> Source/WebKit2/UIProcess/API/qt/qquickwebview.cpp:314 >>> +void QQuickWebViewPrivate::_q_visibleContentRectAndScaleChanged() >> >> Would it be better to make updateVisibleContentRectAndScale a slot? > > Well it is in QQuickWebViewPrivate, and all the other slots there have the _q_something form. and? what is wrong with renaming it?
Allan Sandfeld Jensen
Comment 9 2012-01-31 05:17:20 PST
(In reply to comment #8) > (From update of attachment 124550 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=124550&action=review > > >>> Source/WebKit2/UIProcess/API/qt/qquickwebview.cpp:314 > >>> +void QQuickWebViewPrivate::_q_visibleContentRectAndScaleChanged() > >> > >> Would it be better to make updateVisibleContentRectAndScale a slot? > > > > Well it is in QQuickWebViewPrivate, and all the other slots there have the _q_something form. > > and? what is wrong with renaming it? Well nothing, but it is called from a other functions, and it seemed like a poor name for a function. I don't know the motivation behind the slot naming scheme, I was just trying to follow it, and it seemed most slots where thin wrappers.
Simon Hausmann
Comment 10 2012-01-31 06:15:19 PST
Comment on attachment 124550 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=124550&action=review >>>>> Source/WebKit2/UIProcess/API/qt/qquickwebview.cpp:314 >>>>> +void QQuickWebViewPrivate::_q_visibleContentRectAndScaleChanged() >>>> >>>> Would it be better to make updateVisibleContentRectAndScale a slot? >>> >>> Well it is in QQuickWebViewPrivate, and all the other slots there have the _q_something form. >> >> and? what is wrong with renaming it? > > Well nothing, but it is called from a other functions, and it seemed like a poor name for a function. I don't know the motivation behind the slot naming scheme, I was just trying to follow it, and it seemed most slots where thin wrappers. The reason for the _q_ in the name is that those slots are technically visible from the outside - Q_PRIVATE_SLOT only affects how a slot is implemented, not its visibility to the outside. Therefore we introduced the naming convention in Qt to say slots that start with _q_ are "internal" in the ABI/API sense and do not come with any compatibility guarantee.
Allan Sandfeld Jensen
Comment 11 2012-01-31 06:45:55 PST
WebKit Review Bot
Comment 12 2012-01-31 06:49:48 PST
Attachment 124719 [details] did not pass style-queue: Failed to run "['Tools/Scripts/update-webkit']" exit_code: 9 Updating OpenSource First, rewinding head to replay your work on top of it... Applying: Fix compilation errors on build-webkit --debug --no-workers on mac. Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging LayoutTests/ChangeLog CONFLICT (content): Merge conflict in LayoutTests/ChangeLog Auto-merging LayoutTests/platform/qt/Skipped CONFLICT (content): Merge conflict in LayoutTests/platform/qt/Skipped Auto-merging Source/WebCore/ChangeLog CONFLICT (content): Merge conflict in Source/WebCore/ChangeLog Failed to merge in the changes. Patch failed at 0001 Fix compilation errors on build-webkit --debug --no-workers on mac. When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To restore the original branch and stop rebasing run "git rebase --abort". rebase refs/remotes/origin/master: command returned error: 1 Died at Tools/Scripts/update-webkit line 164. If any of these errors are false positives, please file a bug against check-webkit-style.
WebKit Review Bot
Comment 13 2012-01-31 09:09:28 PST
Comment on attachment 124719 [details] Patch Clearing flags on attachment: 124719 Committed r106362: <http://trac.webkit.org/changeset/106362>
WebKit Review Bot
Comment 14 2012-01-31 09:09:33 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.