Bug 77339 - [Qt] Painting on wheel scroll
Summary: [Qt] Painting on wheel scroll
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Allan Sandfeld Jensen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-30 07:45 PST by Allan Sandfeld Jensen
Modified: 2012-01-31 09:09 PST (History)
4 users (show)

See Also:


Attachments
Patch (6.23 KB, patch)
2012-01-30 07:49 PST, Allan Sandfeld Jensen
no flags Details | Formatted Diff | Diff
Patch (6.94 KB, patch)
2012-01-31 06:45 PST, Allan Sandfeld Jensen
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Allan Sandfeld Jensen 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.
Comment 1 Allan Sandfeld Jensen 2012-01-30 07:49:53 PST
Created attachment 124550 [details]
Patch
Comment 2 Kenneth Rohde Christiansen 2012-01-30 08:26:44 PST
Comment on attachment 124550 [details]
Patch

wouldnt it be better to call the viewportTrajectoryVectorChanged ?
Comment 3 Andras Becsi 2012-01-30 08:43:55 PST
I think this is the same issue as https://bugs.webkit.org/show_bug.cgi?id=77338.
Comment 4 Allan Sandfeld Jensen 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.
Comment 5 Andras Becsi 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.
Comment 6 Alexis Menard (darktears) 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?
Comment 7 Allan Sandfeld Jensen 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.
Comment 8 Alexis Menard (darktears) 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?
Comment 9 Allan Sandfeld Jensen 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.
Comment 10 Simon Hausmann 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.
Comment 11 Allan Sandfeld Jensen 2012-01-31 06:45:55 PST
Created attachment 124719 [details]
Patch
Comment 12 WebKit Review Bot 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.
Comment 13 WebKit Review Bot 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>
Comment 14 WebKit Review Bot 2012-01-31 09:09:33 PST
All reviewed patches have been landed.  Closing bug.