JDK-8125960 : WebView is not using accelerated compositing for http://javaweb.sfbay.sun.com/~epavlova/Performance/JavaFX2/mexsantos opacity transitions
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2012-09-05
  • Updated: 2015-06-17
  • Resolved: 2012-09-12
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
8Resolved
Related Reports
Relates :  
JDK-8101730 - Implement and enable accelerated compositing to improve WebView rendering performance
Description
Although certain manual tests suggest that accelerated compositing (RT-22913) does improve performance of opacity transitions on http://javaweb.sfbay.sun.com/~epavlova/Performance/JavaFX2/mexsantos, debugging shows that these transitions do not actually trigger accelerated compositing. This strange situation needs to be investigated.
Comments
It turns out the observation that accelerated compositing improves performance of "mexsantos" opacity transitions was incorrect. It resulted from me running outdated JavaFX bits to obtain baseline numbers. Comparing WebView with and without accelerated compositing now, I see no difference in performance on http://javaweb.sfbay.sun.com/~epavlova/Performance/JavaFX2/mexsantos, which is expected, as debugging shows that the page in question does not really trigger accelerated compositing in WebView. As a matter of fact, the page does not trigger accelerated compositing in either Chrome or Apple's WebKit port for Windows, too. That means WebView is consistent with other WebKit browsers here, so I am closing this JIRA entry as not an issue. For those wondering why accelerated compositing does not take place in this case, it is because the page animates opacity transitions by directly changing element attributes over time, instead of using CSS animations. The latter lets WebKit employ accelerated compositing, whereas the former gives WebKit no chance to do so, that's is why we are not seeing accelerated compositing in this case. FWIW, the page animates transitions using jQuery 1.5.1, a very old version of jQuery. That explains why the page does direct attribute changes instead of CSS animations.
12-09-2012