We have received multiple reports of strangely colored graphics output from the field. We have a machine on which we can reproduce the problem in the lab. Windows 7, 64 bit, Intel(R) HD Graphics driver. It appears that the color component order for glReadPixels is not receiving what it expects. The alpha channel certainly seems to be red by this observed incorrect rendering: black -> red red -> red green -> yellow blue -> magenta To eliminate our system from the problem, the Gears demo runs perfectly fine when using a GLCanvas, but exhibits the color component order problem when switched to use a GLJPanel. Certainly the Intel driver has earned its place on the usual suspects list. This suspicion is strengthened by the fact that glGetting GL_IMPLEMENTATION_COLOR_READ_FORMAT and GL_IMPLEMENTATION_COLOR_READ_TYPE both result in glErrors. However, the colors are correctly rendered on the exact same machine when using jogl 1.1.1a. I was hopeful when I discovered that jogl 1 uses GL_UNSIGNED_INT_8_8_8_8_REV (as opposed to GL_UNSIGNED_BYTE in jogl 2). Sadly, using GL_UNSIGNED_INT_8_8_8_8_REV in jogl 2 did not solve the problem. Still, the fact that jogl1 can correctly handle this problem gives me hope.
Is this reproducible w/ one of our unit tests, i.e. TestGearsES2GLJPanelAWT, which performs a 'snapshot' via ReadPixels (but w/ 3 components only, you may tweak it) ? If not, please provide a unit test and probably a trace log of the same, best w/ latest aggregated build available (-> wiki). The fallback values: 3 components: dFormat = GL.GL_RGB; dType = GL.GL_UNSIGNED_BYTE; 4 components: dFormat = GL.GL_RGBA; dType = GL.GL_UNSIGNED_BYTE; should work for all platforms and all GL profiles ofc.
(In reply to comment #1) > Is this reproducible w/ one of our unit tests, i.e. TestGearsES2GLJPanelAWT, > which performs a 'snapshot' via ReadPixels (but w/ 3 components only, you > may tweak it) ? > > If not, please provide a unit test and probably a trace log of the same, > best w/ latest aggregated build available (-> wiki). > > The fallback values: > 3 components: > dFormat = GL.GL_RGB; > dType = GL.GL_UNSIGNED_BYTE; > > 4 components: > dFormat = GL.GL_RGBA; > dType = GL.GL_UNSIGNED_BYTE; > > should work for all platforms and all GL profiles ofc. Note: The fallback has been introduced w/ commit b33bdf41cf53f37203643a8551bf5d94b42a8fab http://jogamp.org/git/?p=jogl.git;a=commit;h=b33bdf41cf53f37203643a8551bf5d94b42a8fab
(In reply to comment #0) > We have received multiple reports of strangely colored graphics output from > the field. > > We have a machine on which we can reproduce the problem in the lab. Windows > 7, 64 bit, Intel(R) HD Graphics driver. > Hi Please can you indicate the version number of your driver and the exact name of your Intel chipset?
I have run the junit tests on the offending system. A summary of the results of TestGearsGLJPanelAWT can be found here: http://www.cs.cmu.edu/~dennisc/jogl/bug838/TestGearsGLJPanelAWT.html Note that only the default capabilities exhibit the problem. Requesting pixel buffer, or multisampling, or bitmap all seem to get the graphics driver to behave. I was able to "solve" the problem on our end by adding: caps.setPBuffer( true ); for our GLJPanels. Is there any reason to not do this? Should this be added to GLJPanel's constructor within the existing code below? // Works around problems on many vendors' cards; we don't need a // back buffer for the offscreen surface anyway { GLCapabilities caps; if (userCapsRequest != null) { caps = (GLCapabilities) userCapsRequest.cloneMutable(); } else { caps = new GLCapabilities(GLProfile.getDefault(GLProfile.getDefaultDevice())); } caps.setDoubleBuffered(false); offscreenCaps = caps; } bonus note 1: the results of the junit tests are available via http://www.cs.cmu.edu/~dennisc/jogl/bug838/results/ bonus note 2: the junit tests eventually threw an exception: http://www.cs.cmu.edu/~dennisc/jogl/bug838/test_run_error.txt
(In reply to comment #3) > (In reply to comment #0) > > We have received multiple reports of strangely colored graphics output from > > the field. > > > > We have a machine on which we can reproduce the problem in the lab. Windows > > 7, 64 bit, Intel(R) HD Graphics driver. > > > Hi > > Please can you indicate the version number of your driver and the exact name > of your Intel chipset? I sadly have limited access to this machine. I will report the complete details the next time I have the opportunity.
(In reply to comment #4) > I was able to "solve" the problem on our end by adding: > > caps.setPBuffer( true ); > > for our GLJPanels. > > Is there any reason to not do this? Should this be added to GLJPanel's > constructor within the existing code below? one reason not to do this is pixel buffers have a serious problem on linux (getWidth and getHeight do not seem to work correctly which will be the subject of a future bug report).
Dennis .. can you still reproduce the bug w/ latest build, i.e. maven 2.1.0-rc-20131004 http://jogamp.org/deployment/archive/master/gluegen_726-joal_484-jogl_1098-jocl_854 http://jogamp.org/deployment/archive/master/gluegen_726-joal_484-jogl_1098-jocl_854-signed/ ?