JDK-8088905 : New "shared textures" do not share pixel update flags as well as they should
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2012-10-26
  • 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 :  
Description
The fix for RT-24566 introduced the internal concept of shared textures that share a common VRAM texture, but have different information in their Java object wrapper (such as the wrap mode that they expect to use).

The code that ensures that the latest pixels have been loaded to a texture from its in-memory representation uses flags in the Texture object to test if the image data is newer than the VRAM pixels, but the flags are not maintained properly between 2 shared textures that point to the same VRAM representation so we can end up with cases where the same image data must be uploaded more than once (i.e. once per shared version of the texture).  This is a minor performance issue since it would only arise in odd circumstances, such as when an image is shared between an ImageView and an ImagePattern and that image is constantly changing.