Bug 124396

Summary: Few webpages flicker(shift in offset) while scrolling
Product: WebKit Reporter: Praveen Jadhav <praveen.j>
Component: WebKit2Assignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: cmarcelo, commit-queue, dev_sachin, enmi.lee, gyuyoung.kim, kenneth, luiz, marcelo.lira, noam, sergio, zeno
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 125943    
Bug Blocks:    
Attachments:
Description Flags
P
none
Patch none

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
Patch (1.92 KB, patch)
2013-11-15 00:23 PST, Praveen Jadhav
no flags
Praveen Jadhav
Comment 1 2013-11-15 00:21:41 PST
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.