JDK-8087599 : FontSmoothingType is not propagated correctly to the nested graphics context if the render queue is (auto-)flushed via WCRenderQueue.flush
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2012-09-05
  • Updated: 2018-09-05
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8101730 - Implement and enable accelerated compositing to improve WebView rendering performance
Description
See the change made to rt-closed/javafx-ui-webnode/src/com/sun/webpane/platform/graphics/WCRenderQueue.java by RT-22913:

    http://javaweb.us.oracle.com/jcg/fx-webrevs/RT-22913/1/rt-closed/javafx-ui-webnode/src/com/sun/webpane/platform/graphics/WCRenderQueue.java.udiff.html

Note that the font smoothing type is not passed to the nested graphics context if the render queue is flushed via WCRenderQueue.flush. This problem affects not only accelerated compositing layers, but all ImageBuffers, since all our image buffers have auto-flushable render queues.

The problem could easily be fixed if we could get from the nested render queue to the owner render queue or WebPage. Unfortunately, that is currently impossible, even though conceptually every render queue belongs to a WebPage.

One way to fix this problem would be:
1) Get rid of automatic flushing of render queues
2) Flush nested render queues forcefully from WebPage, in a centralized manner, somewhere in between the pulse and "update content" phases