JDK-8144263 : [WebView, OS X] Webkit rendering artifacts with inertia scrolling
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u60,9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • Submitted: 2015-11-30
  • Updated: 2017-01-30
  • Resolved: 2016-12-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u131Fixed 9Fixed
Description
Open Ensemble (don't forget to specify proxy settings in command line if necessary).
Open any sample, open any related document.
This will open a Webview window with the javadoc.
Resize the window so that horizontal scrollbar occupies about half of the window width.
Now position it at the center and swipe with two fingers to the right.
Sometimes this will produce artefacts which can be seen in the attached screenshot.
Comments
Changeset: c7079a11fde0 Author: ghb Date: 2016-12-07 13:58 -0800 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/c7079a11fde0
07-12-2016
+1
03-12-2016
lgtm
29-11-2016
Updated webrev : http://cr.openjdk.java.net/~ghb/8144263/webrev.01/ RC : Dirty rects were not translated due to missing total scroll delta. In between Renderthread if there is more than 2 scroll event (Which are fired from Event Thread due to mouse / trackpad scroll events) which has diagonal scroll position, Successive dirty rects were not translated. Current implementation Scroll() a.Copy Region which needs to be moved to new location. b.Translate earlier dirtyRects to new position based on current dx,dy. c.Update / Append dirtyRects which needs to be rendered / decoded from RenderQueue. Assuming webview window size (467, 467), 16 pixel will be used for scroll bar on both direction and content will be rendered in 450x450 window. if we scroll diagonally, scroll events (from native) are as below S1 : (0, 0,450, 450), dx, dy (0, -50) S2 : (0, 0,450, 450), dx, dy (-50, 0) S3 : (0, 0,450, 450), dx, dy (0, -50) S1 : (0, 0,450, 450), dx, dy (0, -50) : a. Copy Region (0, 50, 450, 400), (0, -50): ��� rects450.png fig 1 b. dirtyRects (EMPTY) c. dirtyRects, d1 (x:0.0 y:400.0 w:450.0 h:50.0) ��� rects450.png fig 2 S2 : (0, 0,450, 450), dx, dy (-50, 0) : a. Copy Region (50, 0, 400, 450), (-50, 0): Ref rects450.png fig 6 b. dirtyRects : d1 (x:0.0 y:400.0 w:450.0 h:50.0) ���> d1��� (x:-50.0 y:400.0 w:450.0 h:50.0) ��� rects450.png fig 3 c. dirtyRects, d1��� (x:-50.0 y:400.0 w:450.0 h:50.0) , d2 (x:400.0 y:0.0 w:50.0 h:450.0) ��� rects450.png fig 4 S3 : (0, 0,450, 450), dx, dy (0, -50) : a. Copy Region (50, 0, 400, 450), (-50, 0): Ref rects450.png fig 1 b. dirtyRects : d1 (x:0.0 y:400.0 w:450.0 h:50.0) Doesn���t intersect !!! d2 (x:400.0 y:0.0 w:50.0 h:450.0) ���> (x:400.0 y:-50.0 w:50.0 h:450.0) ��� rects450.png fig 5 c. dirtyRects, d1��� (x:-50.0 y:400.0 w:450.0 h:50.0) , d2��� + Union of d3 (x:400.0 y:-50.0 w:50.0 h:450.0) ��� rects450.png fig 7 With these three iteration of scroll we have 3 COPYREGION, where 2 are redundant. 1 missing dirtyrect which is failed in S3.b, Ref rects450.png fig 7 and 8. To Over come this problem, Persist the scroll delta and aggregate (add) previous delta to new one, By doing this we will have One CopyRegion and Problem at S3.b will also be addressed. Solution : Added two member variables scrollDx & scrollDy in RenderFrame which holds the accumulated value of scroll delta. scrollDx & scrollDy (x, y) are updated after adding RenderFrame.RenderQueue. These fields (scrollDx and scrollDy) will be reset to 0 in RenderFrame.drop. Compared with previous webrev, I didn���t see any performance overhead.
25-11-2016
Thank you Kevin, Didn't see any visual flicker when i performed scrolling in random direction using Mouse and trackpad, No i haven't measured performance. Will debug 'addDirtyRect' method and update.
01-09-2016
I tested it and it does fix the problem. However, I am a little concerned about the impact on scrolling performance for cases where it is isn't needed, since updateDirty is a fairly heavy-weight operation. I did a quick check and this new call to updateDirty is being called even for pure vertical scrolling. Have you done any performance measurements to see whether we are doing more work in those cases that don't really need it? It looks like the existing addDirtyRect code is trying to handle the case of multiple clip rectangles. Is there a fundamental reason why that won't work? Maybe there is just a bug in the logic.
01-09-2016
webrev : http://cr.openjdk.java.net/~ghb/8144263/webrev.00/ RC : Diagonal scrolling on trackpad (MacBook) will have scroll delta on both direction. ScrollAnimator::handleWheelEvent (native) will call scroll (fwkScroll) for both delta x and delta y. Solution : Update the pending dirty rects (i.e scrollable area). This can occur if there are multiple calls to scroll in the same event thread (i.e mouse wheel event during diagonal scrolling). Difficult to have unit test as it needs pixel level testing. Test : 1. as explained in description or use HelloWebView + any webpage which has more than content area or minimize the webview region. 2. using trackpad do diagonal scroll (to be more precise, scroll in 45 degree).
29-08-2016