WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 118548
124396
Few webpages flicker(shift in offset) while scrolling
https://bugs.webkit.org/show_bug.cgi?id=124396
Summary
Few webpages flicker(shift in offset) while scrolling
Praveen Jadhav
Reported
2013-11-15 00:12:50 PST
In a few webpages where content scale factor is not equal to 1, UI position of content(visible rectangle offset) in webpage is saved after scaling. So, the display offset and content position as saved in WebView are not equal. Whenever there is a request to update viewsize port, the values stored as content position are passed for displaying without rescaling it back. This changes display offset and hence flickers.
Attachments
P
(1.92 KB, text/plain)
2013-11-15 00:21 PST
,
Praveen Jadhav
no flags
Details
Patch
(1.92 KB, patch)
2013-11-15 00:23 PST
,
Praveen Jadhav
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Praveen Jadhav
Comment 1
2013-11-15 00:21:41 PST
Created
attachment 217019
[details]
P
Praveen Jadhav
Comment 2
2013-11-15 00:23:37 PST
Created
attachment 217021
[details]
Patch Patch to recalculate WebPage viewsize port with content scalefactor.
Gyuyoung Kim
Comment 3
2013-11-19 01:41:30 PST
CC'ing Noam. This patch needs to be reviewed by Noam.
Noam Rosenthal
Comment 4
2013-11-19 02:03:54 PST
Marcelo, does this seem right? It seems sensible to me.
Sergio Correia (qrwteyrutiyoup)
Comment 5
2013-11-19 02:41:00 PST
Pra(In reply to
comment #0
)
> In a few webpages where content scale factor is not equal to 1, UI position of content(visible rectangle offset) in webpage is saved after scaling. So, the display offset and content position as saved in WebView are not equal. Whenever there is a request to update viewsize port, the values stored as content position are passed for displaying without rescaling it back. This changes display offset and hence flickers.
Would you have any website to give as an example, that demonstrate this problem?
Praveen Jadhav
Comment 6
2013-11-19 02:50:59 PST
(In reply to
comment #5
)
> Pra(In reply to
comment #0
) > > In a few webpages where content scale factor is not equal to 1, UI position of content(visible rectangle offset) in webpage is saved after scaling. So, the display offset and content position as saved in WebView are not equal. Whenever there is a request to update viewsize port, the values stored as content position are passed for displaying without rescaling it back. This changes display offset and hence flickers. > Would you have any website to give as an example, that demonstrate this problem?
I was going through
http://www.rediff.com
. While scrolling, we can observe blinking effect mentioned in this bug. I have tested this patch on EFL port and it seems to have fixed the problem.
Sergio Correia (qrwteyrutiyoup)
Comment 7
2013-11-19 05:29:22 PST
(In reply to
comment #6
)
> (In reply to
comment #5
) > > Pra(In reply to
comment #0
) > > > In a few webpages where content scale factor is not equal to 1, UI position of content(visible rectangle offset) in webpage is saved after scaling. So, the display offset and content position as saved in WebView are not equal. Whenever there is a request to update viewsize port, the values stored as content position are passed for displaying without rescaling it back. This changes display offset and hence flickers. > > Would you have any website to give as an example, that demonstrate this problem? > > I was going through
http://www.rediff.com
. While scrolling, we can observe blinking effect mentioned in this bug. I have tested this patch on EFL port and it seems to have fixed the problem.
Thanks. I am going to test it on EFL and Nix Minibrowser (as we also use Coordinated Graphics). I have added EunMi Lee, since his patch at
https://bugs.webkit.org/show_bug.cgi?id=118548
is almost identical to this one. He might have insights on this issue.
Gyuyoung Kim
Comment 8
2013-11-19 16:21:48 PST
(In reply to
comment #7
)
> Thanks. I am going to test it on EFL and Nix Minibrowser (as we also use Coordinated Graphics). I have added EunMi Lee, since his patch at
https://bugs.webkit.org/show_bug.cgi?id=118548
is almost identical to this one. He might have insights on this issue.
Yes, this patch seems same one with Eunmi's patch in
Bug 118548
. Eunmi, what do you think ?
Eunmi Lee
Comment 9
2013-11-19 20:53:50 PST
(In reply to
comment #8
)
> (In reply to
comment #7
) > > > Thanks. I am going to test it on EFL and Nix Minibrowser (as we also use Coordinated Graphics). I have added EunMi Lee, since his patch at
https://bugs.webkit.org/show_bug.cgi?id=118548
is almost identical to this one. He might have insights on this issue. > > Yes, this patch seems same one with Eunmi's patch in
Bug 118548
. Eunmi, what do you think ?
Yes, this patch is same with
Bug 118548
. The m_contentPosition(= contentPosition()) is scaled value with contentsScaleFactor, so we have to be careful to use it. The transformToScene() also should be fixed with same reason, so I think it is better to merge
Bug 118548
. Noam, would you review
Bug 118548
? I've fixed for your comments.
Praveen Jadhav
Comment 10
2013-11-26 16:51:29 PST
Lets follow up this issue in
https://bugs.webkit.org/show_bug.cgi?id=118548
. Patch in
Bug 118548
consider more scenarios than that proposed in this bug. *** This bug has been marked as a duplicate of
bug 118548
***
Csaba Osztrogonác
Comment 11
2014-02-13 03:45:43 PST
Comment on
attachment 217021
[details]
Patch Cleared review? from
attachment 217021
[details]
so that this bug does not appear in
http://webkit.org/pending-review
. If you would like this patch reviewed, please attach it to a new bug (or re-open this bug before marking it for review again).
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug