JDK-8095336 : checkState in BaseShaderContext changes the texture unit currently attached to the context
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8
  • Priority: P2
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2013-06-19
  • Updated: 2015-06-12
  • Resolved: 2014-02-11
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
Blocks :  
JDK-8094046 - Poor DisplacementMap effect performance on Mac
Description
During the work on RT-26702 the following issue was discovered:
the BaseShaderContext.checkState method does the following calls: 
   setTexture(0, tex0);
   setTexture(1, tex1);

The setTexture method has a side effect of changing the currently attached texture unit for the context. So, the checkState method changes the current TU to 1. I am not sure if it is an intentional side-effect or not, so assigning this to Graphics team for evaluation.

Before the fix for RT-26702 this did not make any problems, probably because Glass was reassigning the current TU back to 0. However, the fix for RT-26702 changes the way Glass works in rendering on Mac, so this starts to matter.

To see a problem, you need to apply the double_buffering.patch from RT-26702, open any HelloWorld app with a ComboBox and Modena theme and open/close the ComboBox until you se that the contents of the ComboBox was rendered into the main scene. This problem is resolved by switching setTexture lines, however this is not a proper solution.
Comments
Thanks both. I have missed the earlier request. I verified there is no change to the source.
11-02-2014
This is another example of a bug that should not have been resolved as Fixed, since there was no changeset associated with it, and in fact, no bug here. Reopening to resolve as "Not an issue".
11-02-2014
Closed as not verified , no response from dev
11-02-2014
Chien, would you please verify and close this issue?
22-01-2014
I have verified that the real issue was in the earlier proposed patch to RT-26702. It was a state bug introduced in Glass, and this issue been addressed with the updated patch.
12-07-2013
Chien, these warnings do not affect the runtime behavior at all. I have attached a new version of the patch which eliminate the warnings.
09-07-2013
2Petr: I have updated RT-26702 with a line by line port of your eariler double-buffer.patch. I would like you to verify the port and examine the warning messages from the compiler. I have a feeling that might be the source of the problem here when set and unset context may be a NOP.
09-07-2013
No, I suppose the code should always set the TU it needs before doing any operation, but apparently this is not true somewhere later in Prism. I was not sure if the side effect of the checkState method is intensional. If you say it works how it is was supposed to work, than the bug is about some code later which does not reset the TU to 0 when it needs to.
24-06-2013
The setTexture() method was written with the understanding that any code that deals with the currently attached texture unit should set that state before it does any operation. Is there a reason why we need to have an assumed default for which texture unit is set at all times?
19-06-2013