JDK-8101730 : Implement and enable accelerated compositing to improve WebView rendering performance
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 7u6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2012-06-25
  • Updated: 2015-06-16
  • Resolved: 2012-09-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
8Fixed
Related Reports
Relates :  
JDK-8125183 - With accelerated compositing, resizing produces rendering artifacts
Relates :  
JDK-8088576 - DRT test animations/play-state-suspend.html started failing after accelerated compositing was implemented
Relates :  
JDK-8125354 - Solar System CSS3 sample works poorly on Lombard
Relates :  
JDK-8087599 - FontSmoothingType is not propagated correctly to the nested graphics context if the render queue is (auto-)flushed via WCRenderQueue.flush
Relates :  
JDK-8125960 - WebView is not using accelerated compositing for http://javaweb.sfbay.sun.com/~epavlova/Performance/JavaFX2/mexsantos opacity transitions
Relates :  
JDK-8094789 - [D3D, WebView] Accelerated compositing goes black upon returning from screen lock or Clrt+Alt+Del
Relates :  
JDK-8119855 - WebView fails to render famo.us
Relates :  
JDK-8125958 - With accelerated compositing, WebView starts dumping NPEs on http://neography.com/experiment/circles/solarsystem
Description
This feature has a compile time preprocessor guard, USE(ACCELERATED_COMPOSITING), and a runtime setting.
Comments
The fix has been pushed as http://jfxsrc.us.oracle.com/javafx/8.0/scrum/graphics/rt-closed/rev/326aa4129f03 and http://jfxsrc.us.oracle.com/javafx/8.0/scrum/graphics/webnode/rev/f185c41e4b3b
07-09-2012
It was agreed in an off-line conversation that #if PLATFORM(QT) || PLATFORM(GTK) thing in GraphicsLayerTextureMapper.cpp should stay and be augmented with a comment explaining that it was add by the 'JAVA' port. Here is an updated webrev that adds such a comment. http://javaweb.us.oracle.com/jcg/fx-webrevs/RT-22913/3
07-09-2012
It turns out I forgot to update Linux and MacOS export lists. Here is a new webrev in which this problem is fixed. http://javaweb.us.oracle.com/jcg/fx-webrevs/RT-22913/2
07-09-2012
> GraphicsLayerAnimation.cpp: > Could you move normalizedAnimationEndValue() somewhere into platform/graphics/java so as not to pollute shared code? Sure, but then GraphicsLayerAnimation.cpp would need to include a header declaring normalizedAnimationEndValue(), so GraphicsLayerAnimation.cpp would still need to be modified in two places. Furthermore, I would need to duplicate shouldReverseAnimationValue(). Not sure if it is worth the trouble. As a side note, GraphicsLayerAnimation.cpp appears to be a natural home for functions like normalizedAnimationEndValue(), note a new one coming in soon: http://trac.webkit.org/browser/trunk/Source/WebCore/platform/graphics/GraphicsLayerAnimation.cpp#L54 > GraphicsLayerTextureMapper.cpp: > #if PLATFORM(QT) || PLATFORM(GTK) > During a merge it wouldn't be obvious that this code has been added by Java port. Should we rather have #if !PLATFORM(JAVA) ? Well, I do believe it should be #if PLATFORM(QT) || PLATFORM(GTK), matching http://jfxsrc.us.oracle.com/javafx/8.0/scrum/graphics/webnode/file/f4def459c57f/Source/WebCore/platform/graphics/GraphicsLayer.h#l488 Alternatively, I could modify http://jfxsrc.us.oracle.com/javafx/8.0/scrum/graphics/webnode/file/f4def459c57f/Source/WebCore/platform/graphics/GraphicsLayer.h#l488 to read: #if PLATFORM(QT) || PLATFORM(GTK) || PLATFORM(JAVA) static GraphicsLayer::GraphicsLayerFactory* s_graphicsLayerFactory; #endif But that could be confusing as we don't really need s_graphicsLayerFactory stuff in our port. Well, may be it should read #if PLATFORM(QT) || PLATFORM(GTK) || PLATFORM(JAVA), given the recent changes in the WebKit repo (note PLATFORM(EFL) component added): http://trac.webkit.org/browser/trunk/Source/WebCore/platform/graphics/GraphicsLayer.h#L488 Opinions?
05-09-2012
Congratulations! Huge piece of work indeed! A few stylistic comments: GraphicsLayerAnimation.cpp: Could you move normalizedAnimationEndValue() somewhere into platform/graphics/java so as not to pollute shared code? GraphicsLayerTextureMapper.cpp: +#if PLATFORM(QT) || PLATFORM(GTK) During a merge it wouldn't be obvious that this code has been added by Java port. Should we rather have #if !PLATFORM(JAVA) ?
05-09-2012
Here is the patch that implements and enables accelerated compositing in WebView. Webrev: http://javaweb.us.oracle.com/jcg/fx-webrevs/RT-22913/1 webnode/Source/WTF/wtf/Platform.h These changes add definitions that instruct WebKit to turn on accelerated compositing and use the so-called texture mapper. Texture mapper is an approach to accelerated compositing we chose to use in our port. rt-closed/javafx-ui-webnode/src/com/sun/webpane/platform/WebPage.java webnode/Source/WebCore/platform/java/WebPage.h webnode/Source/WebCore/page/java/ChromeClientJava.h webnode/Source/WebCore/page/java/ChromeClientJava.cpp webnode/Source/WebCore/platform/java/WebPage.cpp These changes wire accelerated compositing into com.sun.webpane.platform.WebPage. webnode/Source/WebCore/TargetJava.pri webnode/Source/WebCore/platform/graphics/PlatformLayer.h webnode/Source/WebCore/platform/graphics/texmap/GraphicsLayerTextureMapper.cpp These changes let our port compile the texture mapper stuff. rt-closed/javafx-ui-webnode/src/com/sun/webpane/perf/WCGraphicsPerfLogger.java rt-closed/javafx-ui-webnode/src/com/sun/webpane/platform/graphics/GraphicsDecoder.java rt-closed/javafx-ui-webnode/src/com/sun/webpane/platform/graphics/WCGraphicsContext.java rt-closed/javafx-ui-webnode/src/com/sun/webpane/platform/graphics/WCRenderQueue.java rt-closed/webnode-prism/src/com/sun/webpane/sg/prism/WCGraphicsPrismContext.java These changes arrange for the font smoothing type to be propagated from top level render queues to embedded render queues. Without this, embedded render queues will not have the font smoothing type correctly setup. webnode/Source/WebCore/platform/graphics/GraphicsLayerAnimation.cpp This change fixes WebCore::GraphicsLayerAnimation to apply the animation end state when the animation ends. webnode/Source/WebCore/platform/graphics/texmap/TextureMapper.cpp webnode/Source/WebCore/platform/graphics/texmap/TextureMapperBackingStore.h webnode/Source/WebCore/platform/graphics/texmap/TextureMapperBackingStore.cpp webnode/Source/WebCore/platform/graphics/texmap/TextureMapperImageBuffer.h webnode/Source/WebCore/platform/graphics/texmap/TextureMapperImageBuffer.cpp These files are copied intact from the WebKit repository. webnode/Source/WebCore/platform/graphics/texmap/TextureMapperLayer.h webnode/Source/WebCore/platform/graphics/texmap/TextureMapperLayer.cpp These files are copied from the WebKit repository and modified in order to: 1) Allow WebView to update animations without full layer re-sync 2) Bypass code that attempts to apply erroneous state to a layer when layer animations finish Manual testing: - RT-21820 test: FPS and CPU usage go from 30-35 FPS and 20-23% to 45-49 FPS and 6-10%, respectively (on my laptop) - http://www.webkit.org/blog-files/leaves : CPU usage drops from 5-6% to 2-3%. FPS remain at 50. - http://javaweb.sfbay.sun.com/~epavlova/Performance/JavaFX2/mexsantos (see RT-24279): transitions become noticeably smoother - http://neography.com/experiment/circles/solarsystem: the render thread starts dumping NPEs. Will file a bug and address this regression separately. - No regressions in Ensemble, Browser, WebMap, WebLauncher Automated testing: - No regressions in unit tests - One (out of 16K+) DRT test, animations/play-state-suspend.html, starts failing. The test is also failing in Chrome and Safari, where it produces different results in different runs, so I am going to address this issue separately.
04-09-2012
This fix won't go into 2.2.2 as it depends on the latest Webkit bits that are in Lombard only.
15-08-2012
The article on the chromium blog is excellent. There is another performance issue already related to adding "layers" either explicitly (via API) or implicitly (as we discover such cases) to Prism. RT-23371 and RT-23346 both relate to layers. Looks like this may be something we want to raise in priority.
27-07-2012
Test: http://www.webkit.org/blog-files/leaves
27-07-2012
Good overviews of what accelerated compositing is about: - https://sites.google.com/a/chromium.org/dev/developers/design-documents/gpu-accelerated-compositing-in-chrome - http://www.sencha.com/blog/understanding-hardware-acceleration-on-mobile-browsers
27-07-2012